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scanning behavior that was observable on the network, that 
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five seconds of the issuance of the command, and that the 


clients would return to a failsafe state if communication 








with the command and control server was lost. 
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I. INTRODUCTION 














Department of Defense (DoD) use of information systems 


connected by networks continues to expand, as it arguably 








does for every enterprise level organization in the world 











today. The threats on the Internet—viruses, botnets, hackers 


and the like-form the basis for enormous vulnerability, both 





to the machines of the networks, and to the Department of 





Defense mission that those machines support: protecting the 


security of the United States of America. 


Network administrators perform a vital role in both 








administering and protecting our networks. They carry out 
the myriad tasks essential to the function of the network, 
ranging from the routine to the tremendously complex— 


configuring the host machines, the network hardware, the 





firewalls, interfacing with the system users—the list 





continues ad infinitum. Network administrators form the 





bulwark of our defense, which is referred to as “Information 


Assurance.” 


The traditionally accepted “threat equation” states 








that risk is equal to threats multiplied by vulnerabilities— 





mitigated only by safeguards [1]. Since the safeguards of 








DoD networks, indeed any network, is most fundamentally 


influenced by the skill of its administrators, the primary 

















mitigation of risk to DoD networks (indeed the DoD on the 


whole and ipso facto, the security of the entire nation) 





rests on the quality of training provided to our network 








administrators. When we consider that the threat to our 


networks are ever increasing, aS is our usage of them and 





the concomitant increase in vulnerability, it becomes that 
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much more imperative that we provide the best and most 


effective training possible to our network administrators. 


A. TRAINING NETWORK ADMINISTRATORS 








DoD training of its network administrators relies on a 





wide variety of different methods. Classroom instruction is 


standard, as are mentors performing on-the-job training. 








Instructed laboratory environments are also commonplace. 








Still, the most significant training of DoD network 
administrators in the area of information assurance is 


performed by the use of red teams. Thes red teams are 








composed of highly-trained, specifically-tasked personnel 


that act as adversaries in order to test the networks and 








their administrators by emulating the threats that the 


administrators currently face. 


B. SHORTCOMINGS OF THAT APPROACH 


While classroom training of network administrators is 











essential, it is often considered unsatisfactory for the 





sorts of robust evaluations required in the military 


environment. Laboratory training can be more robust, but 








the training does not evaluate the strengths and weaknesses 
of the actual network of the organization. The red team 
approach is superior in both these areas; the training is 


both robust, and often performed on the operational network 








of the organization. Still, the DoD red teams that perform 





this training are not an unlimited asset. They consist of 


personnel with specialized training requirements, limited 





funding and operational tempo, etc. Reliance on red teams, 











thus, restricts the amount of training available to DoD 








network administrators. This in turn impacts DoD networks 





on the whole, and is therefore a matter of national 


security. 


Cc. OBJECTIVES 


Our objective is to design a network training tool to 





help train administrators—one that can integrate the network 
evaluation into the highly complex training events typical 
of U.S. military training exercises. Towards this, we seek 


to construct a system with the following characteristics: 


e The system must be safe enough for use on the 
operational network, and not constrained for use 


in the laboratory. Towards this, it must be 





inherently benign, externally controllable, and 
include a tested failsafe condition for rapid 
neutralization and/or retraction (rollback) from 


the impacted network. 





e The system must emulate threat behaviors rather 








than duplicating the threats themselves, i.e., the 
system must be constructed of malware mimics, not 


actual malware. 


e The system must be distributed, allowing the 





trainer to be geographically distinct from the 





network and the network administrators undergoing 


training. 


D. ORGANIZATION 








Chapter I provides a brief treatment of the motivation 


for this thesis: mainly, the defense of the United States 








through improved training for the administrators of DoD 
networks. This goal we propose achieving through the use of 


a distributed software system. 











Chapter gives a more formal definition of red teams, 











as well as usage examples of red teams in DoD environment. 











Chapter also gives a brief overview of the current 








threats to networks and enumerates some of their behaviors. 














Chapter covers the design considerations of our 








proposed software solution. We formally defin th 


interested parties in training, as well as the training 





objective, and give an example of how the proposed system 
could be used in an actual training exercise. We give 
further treatment of our stakeholders in training, and 
specifics on what behaviors might be desired that a software 


solution perform. 





Chapter IV has discussion of the actual software 


implementation of the system, to include the Graphical User 

















Interface (GUI). t also discusses the complex test-bed on 


which we tested our implementation. 





Chapter V presents results from our testing of the 











system, to include graphical representation of system 
performance. It shows that the software system we have 
implemented does indeed generat xternally observable 





network behaviors that are remotely controllable. 





Chapter VI is the summary of the thesis, with 





conclusions regarding the outcome. It also enumerates 





future work that could be done on this project, to include 





some of the areas that will require more refinement befor 


the system is ready for a production environment. 


II. BACKGROUND 


This chapter gives more specific treatment of red teams 








used in a DoD setting, to include employment. Additionally, 





some of the threat signatures and behaviors used by red 


teams are discussed, to include bots, worms, and viruses. 


A. RED TEAM 


Red teams are “specially selected groups designed to 


anticipate and simulate the decision-making and behaviors of 





potential adversaries.” [2] The red team forces an 





organization to examine itself critically. No organization 
is perfect, no weapon system is perfect, and no idea is 


perfect. The red team examines whatever it is that needs to 





be evaluated, uncovers its flaws, and finds potential 





weaknesses that can be exploited. Sun Tzu said, “If you 
know your enemy and know yourself you need not fear the 
results of a hundred battles.” [3] Complete knowledge of 


the enemy may be impossible, but through the use of red 





teams, a more thorough knowledge can definitely be gained 


about one’s own organization. 


Red teams are used in all aspects of military planning. 














They are used at the tactical level in mock battles using 
infantry, mechanized, and/or aerial units acting as a real, 
opposing, red force. The two-week, high intensity, Red Flag 


training xercis held at Nellis Air Force Base (AFB), 








Nevada (on occasion at Eielson AFB, Alaska) was created to 





simulate realistic combat missions against a credible and 


live opposing force. Red teams, typically led by staff 














Intelligence Officers, are used in staff planning of future 
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maneuvers to foresee possible reactions or resultant 





movements of the enemy. They are utilized in the creation 





of new weapons or new national or military guidance 





publications, such as the National Security Strategy, Joint 
Strategy Review, and the Maritime Strategy. One example was 
the led by the Naval War College. Most notably, the Global 


War Games from 1984-1988 resulted in many significant 





conclusions that helped to define the Maritime Strategy at 
that time [4]. By having red team think tanks and war gaming 
scenarios, the actions of forecasted adversaries can be 


identified. This information could then sway the future 








actions of the entire DoD. 


From the aspect of cyber-security, red teams are vital 
in the training of the government and military network 
operators. The term operators can be as broad as the entire 
staff, which will include managers and officers, 
administrators, engineers, help desk, and response 


technicians. The term operators in this thesis will limit 








its scope to the administrators, help desk personnel, and 





technicians. 


B. RED TEAM DURING CYBER DEFENSE EXERCISE (CDX) 


One of the two red team examples will come from the 

















annual Cyber Defense Exercise (CDX) that is held between th 








United States Servic Academies, other military academic 





schools (Air Force Institute of Technology and Naval 
Postgraduate School), and on occasion, other nations’ 


military schools (e.g., in 2010, the Royal Military College 








of Canada was part of the competition). The tenth annual CDX 
sponsored by the National Security Agency (NSA) was in 2010 
eons 








In the CDX, it is each school’s mission to design a 


network from scratch, build it in its entirety, fortify it 








and then defend it for an entire week against external and 
internal attack. The network must meet a certain baseline 
such as providing a Web service, domain name service, active 


directory, e-mail, bulletin board, and more. The students 





must research what are the most effective and secure 
operating systems to use. Then, the applications and 
services must be identified, installed, and properly 


configured. These computers and services must then be 





joined to a network which is then linked into the entire 


game network via a Virtual Private Network connection which 





logically removes the game network from the rest of the 











internet. The NSA red team is situated in its own network 
with access to th ntire game network where it can launch 
attacks against all of the competing schools. In the 2010 





competition, the red team had an agent on the inside of each 











school’s network, along with a cluster of five improperly 
configured computers. The agent, acting the part of the 
“ignorant user” could be persuaded to visit malicious 


websites and click on dubious e-mail attachments. 





Getting th ntir xercise network researched, built, 
and operational takes a great deal of effort by students. 


Further efforts are required to harden the computers, 





operating systems, services, and th ntir network. 


Getting th ntire network operational is merely the ante to 











compete in the CDX. For the participants, the real work and 


concomitant training value comes from the competition week 





when the NSA red team begins their attacks. 





As delineated in the Certified Ethical Hacking Manual, 


there are five phases in which an intruder advances the 





attack [6]. The red team followed these typical five 
phases: reconnaissance, scanning, gaining access, 
maintaining access, and covering their tracks. Some steps 


were shortened (reconnaissance, since some information is 





already known) or skipped (covering of tracks, since the 
students need to identify what was compromised). This is 
done so that the students of the competing schools can 
experience what it is like to be scanned, infiltrated, and 
exploited. The detection of the infiltration or the 


witnessing of unintended actions must be noticed, steps 





taken to neutralize the problem, corrective actions taken to 
restore impacted systems, and further research and steps 


taken to prevent that problem from happening again. The red 








team would do their best to infiltrate as many systems as 





possible and leave their mark for the schools to find. 


The red team was limited in what they were allowed to 


use in their attacks. Common hacking software suites, e.g., 





Backtrack and Metasploit, were utilized along with a host of 


other easily available tools that anyone with access to 





hacker sites on the internet could obtain. Current exploits 





and vulnerabilities could also be used if they were present 





on the networks. This encouraged the competing schools to 


review the current literature and download and install the 





current applicable patches for their systems. The red teams 








were not allowed to generate their own malicious code or 





exploits. 


The red team presented a live, thinking opponent to all 


of the competing schools. Automated tools and other 





software were utilized, but th red team members took the 


data that was returned and formulated strategies of what to 





attack next. The intelligent nemy could probe further, 








find out what is installed, and run attacks against known 





vulnerabilities of the running software or installed 


operating systems. Furthermore, the inside red team agent 














was another vector of attack. These two facets taught the 
students to look for attacks from outside and within, how to 
effectively place and use sensors, to research and 
constantly update their systems, and if anything was 


breached, how to investigate, limit the extent of the 








damage, and restor th system to operation with the 


vulnerability removed. 


The only negative aspect of this exercise is that it is 








done on an exercise network. As mentioned previously, the 





point of th xercis is to build and defend a network. 


Therefore, all of the decisions were made with security as 





the top priority. This is not true for every organization 





and every network. Having this exercise done on a true, 


operational network, with all of the requirements and needs 








Os sth user-bas met, and with hundreds or thousands of 





constant users, would make this xercis ven more 
realistic. 
Cc: RED TEAM DURING COMPOSITE TRAINING UNIT EXERCISE 


An example of an exercise that does use the operational 





network is the Composite Training Unit Exercise (COMPTUEX). 








It is the culminating exercise for the qualification of a 








strike group. A strike group of usually five to seven ships 
spends nearly a year in the predeployment workup cycle and 


upon successful conclusion of COMPTUEX, the battle group is 
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assessed to determine its readiness for deployment and for 


battle. The COMPTUEX is an intens xercis that is 








developed to stress the entire group: the staff, the ship’s 
officers, the ship’s crew, the Marines, (if embarked), the 


joint component, and the Air Wing, to name a few. 








COMPTUEX is the time when the onboard computer networks 





are attacked by the red team from the Navy Cyber Defens 





Operational Center. As previously mentioned, COMPTUEX is 
the final exercise for the strike group. The cyber attacks 


are only a small portion of all the attacks that will be 





directed toward these ships. The ships have multiple 
objectives to complete every day. Some events are specific 
to one ship, others to some subset or all of the ships. 


These events affect every person onboard. With the increase 





in workload, the computer networks, communication systems, 


and combat systems are heavily utilized to accomplish the 





many missions set forth by the examiners. It is during this 








tumultuous time that the red team also attacks these vital 


networks. 


All of the events of COMPTUEX are scripted by the 


evaluators at the Center for Surface Force Training Atlantic 








or Tactical Training Group Pacific. Since they are scripted 








and all actions must be graded, there are breaks given so 
that vital systems or groups that must be graded will have 


the tools normally available to them to accomplish their 

















task. Therefore, the red team will not usually target vital 


systems during the war-fighting phases of the training. The 








red team will usually attack during the quieter times of the 


whol xercise. This is difficult for the network 











administrators and technicians: following manning their 
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battle stations during simulated combat operations, they 





must then man their normal shipboard watch stations and 








continue defending from attacks by the red team. 


Purposefully, some of the attacks on the computer networks 





and communication systems are linked to the battle. There 


are specific training objectives designed to take down vital 











communication channels during attacks or evolutions so that 


the ships and watch teams can be evaluated on their 





response. This is to allow the assessment of such questions 
as: “Can the ship fight without their normal complement of 


communication options?” 


In this context, the red team of COMPTUEX performs 








similar functions to the red team of the CDX. The red team 
attempts to scan the system, breach it, and then exploit it. 
Since this training is done on an operational network, 


certain behaviors are desired without the exact malware 





being introduced to the network. Therefore, the red team 


Simulates th ffects of some of the more nefarious attacks. 





The mission of the red team is to test the vigilance of the 











network administrators, technicians and, to an extent, the 





users of that network. Some of the attacks are only 
detectable by the administrators, and then only by reviewing 


the logs of the firewall, intrusion detection systems, and 








other sensors and services. Some of the attacks the users 
will see in malicious emails, odd things happening on their 
work computers, or even strange printouts on networked 
printers. The attacks are varied and thorough, testing all 


equipment, sensors, and people. 


By having a red team attack an operational network, the 


training and evaluation are much more realistic. The actual 
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network administrators, technicians, help desk, and users 


are tested on the computers and equipment they use every 











day. This is the environment with which they are most 
comfortable. More importantly, these are the networks that 
will be used prior to and during the battle. Upon 





completion of the associated training and evaluations, the 





IT professionals on the ship now know the strengths and 
weaknesses of their own network. They know how to use their 
sensors and know what the sensors can and cannot reveal. 
Also, they may find that their network has some derived 


vulnerabilities due to the other systems with which it must 





interface. Thes are th residual risks that exist within 





all organizations. 


The major downside to the training is that the full 








repertoire of attacks may not have been used because it is 
an operational network. The risk of corrupting or 
destroying the operational network could cripple the ship 


for days, weeks, or more depending on the attack. Such cases 





would be detrimental to the strike group readiness, likely 





preventing th on-tim deployment of the strike group 





(COMPTUEX is usually immediately prior to the end of the 





workup cycle). Therefore, attacks of such intensity must 
either be avoided or simulated to some extent. The red team 
may not use them, but a true adversary would likely have no 


restrictions on what is or is not allowed. 


D. A RED TEAM APPROACH USING RAD-X 


An example of an interesting approach using red-team 








methodologies is the Defense Information Systems Agency’s 











(DISA) use of the Rapid Experience Builder (RaD-X) training 








tool. RaD-X is essentially a portable network training 
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laboratory, isolated from the operational network and the 





Internet, allowing for its use as a “sandbox” for network 








administrator students to observe network exploits as they 


occur. With this tool, users can observe many of the 





threats discussed below-worms, botnets, viruses and the 


like-by use and analysis of intrusion detection and 





intrusion prevention systems organic to the system. RaD-X 


includes instructional courseware and _ formal laboratory 








exercises that complement the training the students receive 


while utilizing the laboratory network. Though portable, 





the footprint is significant: the system includes a large 





number of laptop computers and concomitant network hardware, 


as it is a self-contained training network [7]. 


E. RED TEAM EXPERIENCE 


Exercises verses a red team is the pinnacle of a unit’s 











training. It is utilized in the capstone evaluation of this 


country’s deploying forces. The red team provides training 








that is as realistic as possible. It can produce an 





xperience like no other. 


As mentioned in the previous sections, the red team can 


attack from a multitude of vectors. Only a small subset of 





the attacks that the red team utilizes will be examined. The 





attacks that are examined are some of the most dangerous and 








disruptive to network security today. 
F. MALWARE 


A computer is a tool that executes instructions, or 
programs, at a very rapid pace. For the most part, a benign 


program does productive work, safely interacting with the 
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components of computer, such as the processor, the files on 


the hard drive, and other processes and data in memory. 





Malicious programs perform work or actions that the user 





does not want and ends with results that are insulting, 














frustrating, and/or damaging. Spam e-mail fits into all of 
those categories. Virus logic bombs that destroy critical 
files are incredibly damaging. Denial of Service attacks on 


e-commerce sites can be frustrating for the customer and 


potentially damaging for the business, normally resulting in 








lost business and revenue. Root-kits that allow unauthorized 


access to other people’s or organization’s computer 





resources are a significant security risk, and usually 


causing some form of loss or damage. 


“Malware” is the overarching term used to describe the 





programs that force the computer to xecut thes 
misbehaving tasks. The types of malware that will be 


considered herein are: worms, botnets and viruses. 


1. Worms 


A worm is stand-alone malicious code that propagates 
across the hosts of a network, with or without human 


assistance—no interaction on the part of a user is required. 





According to Gu (et al.), there are thr characteristics of 











an Internet worm: 





e Internet worms generate a substantial volume of 





identical or similar traffic. This can be 
detected by passive listening on the network, as 
performed by protocol analyzers like Wireshark or 











Intrusion Detection Systems like Snort. 
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e They use random scanning to probe for vulnerable 


hosts, which can also be detected by those passive 





listeners. 


e Compromised hosts exhibit predictable signatures: 
an uninfected host would have “normal” traffic, 
but when infected, the host begins random scanning 


looking for other vulnerable hosts on the network. 





In addition to propagating itself by finding additional 


vulnerable hosts, worms typically have some other malicious 








function. It may direct users to certain websites or it may 
collect information from the infected host and report it 
back to some central computer. It could also be malicious 


and try to destroy key files on the host computer [8]. 





Some examples of worms include the Morris worm (1988) 
[9], the first known instance of a worm, as well as the 


Nimda and the Code Red worms [10]. 


2. Botnets 


Bots and networks of bots (“botnets”) are emerging as 
the most significant threat facing online ecosystems and 


computing assets [11]. Like viruses and worms, a bot is a 





self-propagating application (code) that infects vulnerable 
hosts through exploit activities in order to expand the 


reach of the Bot network [11]. Bots can use worms or other 





bots to propagate to other computers on the network. 


Bots can be distinguished from viruses and worms by 
their command and control characteristic: bots will normally 
include facilities that allow for control by some sort of 


Command and Control structure, be it a single server or some 
ils) 





type of distributed system. Since bots can be controlled by 


a single entity, they can be remotely directed towards a 





single purpose. A typical use for a bot is a Distributed 











Denial of Service (DDOS) attack, where a massive number of 


bots can coordinate their traffic in order to overwhelm a 





network server [11]. 





Bot behaviors include those of worms outlined above, 


with the addition of command and control traffic that rides 





within different protocols: commonly Hyper Text Transfer 





Protocol (HTTP) and Internet Relay Chat (IRC). In actual 














bots, this traffic may or may not be encrypted. Detection 
of bots through passive packet monitoring (as above-with 
protocol analysis by tools such as Snort or Wireshark) of 


data streams can be useful, as bots will often exhibit 





typical signatures or behaviors. Like worms, the scanning 
behaviors used for propagation can also b detected 
passively and the results used for bot (and worm) 
identification [11]. Bots will often remain hidden until 





they receive instruction from the command and control server 











to execute some action, which is typically a denial of 


service attack as described above [12], [13]. 


Perhaps the most widely known example of a bot is 





“Conficker,” which is still active at the time of this 


writing. One estimate of Conficker held it responsible for 





8.9 million infections, and it appeared in a variety of 
different networks, including those of the German and 


British Armed Forces [14]. 
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3. Viruses 





In Peter Czor’s The Art of Virus Research and Defense, 








he defines a computer virus as ™“..code that recursively 
replicates a possibly evolved copy of itself. Viruses 
infect a host file or system area, or they simply modify a 
reference to such objects to take control and then multiply 


again to form new generations.” [15] 


Viruses can be classified by many categories. These 
include what computer architectures they target, such as 
processor types or operating systems; file systems and file 


formats; interpreted nvironments such as_ scripts (PHP, 





Jscript, Batch and Shell scripts) and macros; and more. 
They can also be classified as to how they infect, such as 


boot records, files, and in-memory. They could be 





classified as to their defensive mechanisms, like tunneling, 
armored, retroviruses, morphing and encrypting. Finally, 


they could be classified according to their payload, whether 





it is intended to be benign and non-destructive, 


destructive, data-stealing, or denial of service. 


Since all viruses ar cod and that code must reside 





somewhere on the host, the signature-based virus scanner 
periodically searches for those classic signatures on a 


system. Only new viruses or emerging variants of existing 








viruses will cause the scanner to fail to match the stored 


signatures and claim that the code is safe. 


A canonical example of a virus is the “Anna Kournikova” 
virus. Although it did not have a malicious payload, it made 
its way through a bulletin board posting, through mass-— 


mailing capability, and social engineering (enticing people 








with a new picture of Anna Kournikova) to spread itself 
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around the world. The file was a visual basic script: 





AnnakKournikova.jpg.vbs. It duped the user into executing 


the script, e-mailing itself with the VBS attachment to 














everyone in the user’s mail address book. Its payload was 
nothing except spam e-mails that quickly spanned the world 


[16]. 


G. SUMMARY 





In this chapter, we discussed the usage of red teams 











used in a DoD setting, and examples of exercises in which 





they are employed. We also discussed some of the threat 


signatures and behaviors used by red teams, including bots, 





worms, and viruses. In the following chapter, we assert 














that DoD use of red teams constrains how we train, and 


propose a information system solution. 
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IIIT. DESIGN CONSIDERATIONS 





In this chapter, we make a few definitions, namely 


those of the “training objective” that we are training to, 








the “trainees” that are receiving the training, the 


“trainers” that train them, and the “safety observers” that 





observe all of the above. We scope our discussion by a 


defining the training “environment,” as well as identify the 











problems with the DoD’s current approach to network 


training. We proposed an information systems solution to 





those problems and give a detailed example scenario of its 





use. We conclude the chapter with more detailed discussion 


of the above elements. 


A. THE TRAINING OBJECTIVE 





In order to simplify discussion, we make an initial 





definition: the training objective. The training objective 


is the skill or behavior that we wish to reinforce. We mak 





no comment on the size, complexity, or specifics of the 





training objective-they can range from the simple to the 


very complex, e.g., from “pull the trigger” to “win the 











war.” We limit our scope of training objectives to the 
specific behaviors that result from trainee interaction with 
malware/mal-behavior and its accompanying effects. We also 
assume that training objectives correspond to specific 
threats which have specific behaviors. Further, we do not 
discuss any specific training methodology or algorithm, as 
it is beyond the scope of this thesis. Below, we include an 


example training scenario, with its training objective. 
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In order to discuss any training tool, we must also 





identify the stakeholders. Towards this, we propose three 


generalized parties typical in a military training 





environment and indeed, most training environments: the 


Trainee, the Trainer, and the Safety Observer. 


B. THE INTERESTED PARTIES IN TRAINING 


1. The Trainee 


The “trainee” iS a person or group of persons in the 
organization that we wish to be trained to the training 


objective. Specific examples could include network 





operations personnel, or perhaps even further up the stack 


of decision making, e.g., network managers. 


2. The Trainer 


The second participant in training is the “trainer.” 


The trainer is the person or organization that presents 








specific scenarios of behaviors to the trainee in order to 
evaluate the trainee’s performance vis-a-vis the training 


objective. Typical examples of trainers in military networks 








include “red teams” (who simulate the Tactic, Techniques, 
and Procedures (TTP) of adversaries) as well as less 
formalized trainers, e.g., the mor xperienced network 
operator training the less experienced. In “high school” 











parlance, the trainee is the student, and the trainer is the 


teacher, though this relationship is not excluSive, i.ée., 











the trainer may or may not b th on giving the 








instruction, but the trainer is limited to testing the skill 














of the trainee. 
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3°. The Safety Observer 


The third participant in training is the safety 





observer. In many training scenarios, we need to define a 
party separate from the trainer and the trainee that is 


responsible for maintaining oversight of the conduct of the 








training. For example, during safety critical training, 








there is often a safety observer, whose scope of attention 





exceeds that of the training activities to include the 








impact of the training on the organization as a whole. In 
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military training” parlance, this could be members of a so- 








called “White Cell.” Note that circumstance will sometimes 








dictate that either the trainer or trainee fill this role, 





e.g., in those training scenarios where the risk of training 
does not warrant the use of a separate party. A specific 


example would be that of a senior network administrator 





tutoring a junior administrator while utilizing an isolated 





(non-networked) host. An example of a needed _ safety 





observer would be training of such complexity that the 
trainer and trainee could not effectively train while 
simultaneously ensuring their training would not impact the 
safety of the organization, e.g., a large scale training 


scenario involving integrated operations from multiple major 











departments. Network training on an aircraft carrier network 
during flight operations and engineering drills would be an 


example of this. 


Cc. THE TRAINING ENVIRONMENT 








Now that we have discussed the interested parties in 


our discussion of training, we must discuss the training 





environment. For the purpose of this thesis, we limit 
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ourselves to training the administrators of military 


networks. That said, military networks vary enormously in 





terms of size and complexity, ranging from the completely 





isolated host in the training laboratory to the entire 





Global Information Grid, the military's global 
communications backbone comprising 15,000 networks and seven 


million computing devices across hundreds of installations 








in dozens of countries [17]. Note that DoD networks also 


span different classification levels, though we will not 








treat th requirements contained in these differences. 





Military networks include those of an administrative nature, 





e.g., training laboratories for network personnel, as well 
as networks of an operational nature, where lives and 
mission success literally depend on their effective 


utilization. 





The differences between thes networks also indicate, 





ipso facto, greatly varying network infrastructure and 








topologies. Some DoD networks have network firewalls, some 





have multiple tiers of them, and some have none. Some 
networks are completely hidden inside Network Address 


Translation realms, and some are outward facing onto the 








global Internet. Some networks are connected by high 





bandwidth fiber-optic cable, while others are connected by 


low-speed, high-latency satellite connections that offer 





slightly better connectivity than low-speed  telephon 


modems. 


D. HOW WE CURRENTLY TRAIN 





The treatment Aland gives in the International Test and 


Evaluation Association Journal gives an excellent and timely 
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overview of the challenges faced by DoD leadership regarding 








Testing and Evaluation of DoD network Information Assurance, 





some of which are included below [18]. 


1; Dependence on Red Teams 








One problem that the DoD faces with regards to training 


is that we depend heavily on red teams. Red teams are a 





resource heavily in demand, provided by agencies that are 
faced with increasingly austere fiscal environments. By use 


of this constrained resource, we limit the training options 





available. An exercise planner simply cannot count on a red 





team being available for every exercis 





2. Standardization 


Given the complexity of military networks, it is not 





hard to imagine that maintaining uniformity in training 


throughout a global organization is a difficult task. 











Although the DoD continues efforts to centralize network 





training, there remain disparate organizations using 


disparate tools and methodologies. For example, it is not 





uncommon for a single unit to be trained by National 
Security Agency (NSA) Red and Blue Teams, for personnel to 
be serving as mentors in the same organization as the 


trainee, or for organizational training teams to exist at 





every echelon within an organization—all using a variety of 





different methods. For this reason, it is difficult to 








maintain standardization in training across the different 











networks in the DoD. 








In addition to disparate organizations participating in 





the training, there are different organizations managing the 
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different networks as well. Each of these network management 


bodies imposes its own requirements on the trainers in order 





to minimize the impact of network training on the operations 


of the organization. 





It is also possible for the organization to confine 
their network training to a laboratory environment, vice the 


operational network, in order to minimize the impact of the 



































training on operations. A great example of this is the 
NSA’sS annual Computer Defense Exercis (CDX), discussed in 
Chapter : a geographically distributed but logically 
isolated xercis network. The DoD keeps much of its 








training in the laboratory for good reason; one does not 


want to risk network behavior having negative effects on a 





unit’s primary operational (non-network) mission. Robust 
network training, to a large degree, is considered too risky 
for operational units. Some training methodologies, e.g. 


the release of a worm along the lines of Morris (discussed 











in Chapter ), could have unpredictable results. Consider, 





for example, the trainer’s use of a worm whose effects were 
intended to be limited to the unit under assessment, but 


instead spread over th ntire organizational network. 

















Unfortunately, this deprives the operational units of 
the opportunity to observe how collateral network effects 


can affect the organization as a whole, e.g., seeing how the 








loss of a tertiary air traffic control information system 


due to a virus can affect the launching and recovery of 





aircraft. For this reason, it is imperative that network 
training not be limited to the laboratory, but instead be 


integrated into a holistic assessment of the unit. 
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E. AN INFORMATION SYSTEM SOLUTION 


For these problems, we propos th development of a 





distributed, software-based training system that can be used 





by either simulated adversaries (such as red team) or 
trusted agents (such as blue team) to create scenarios and 


conditions to which a network management/defense team will 








need to react and resolve. This system will be composed of 


currently available software packages and/or “homegrown” 





(locally generated) packages with the desired functionality. 








It will include clients that function as “Malware Mimics,” 








that is, software objects that intrinsically demonstrate 





externally observable attributes of the malware which it 





mimics, to include behaviors and possibly signatures, 








without putting the hosting network at risk. The Malware 
Mimic Client will be constructed in such a way as to depict 
a variety of these behaviors, with sufficient flexibility 
for additional behaviors to be “bolted-on” as they are 


developed later in the system’s life, resulting in a 





sustainable evolution of the product. This Malware Mimic 





System must be inherently benign, externally controllable, 
and include a tested “failsafe” condition for rapid 


neutralization and/or retraction (rollback) from the 





impacted network. The tool should be scalable in order to 





depict the full range of malware characteristics, from low 
sophistication through high sophistication, and adjustable 


in real time. 


Specifically, we propose that the system be composed of 
two types of software packages: Malware Mimic Clients (MM-— 
Clients), and a central Malware Mimic Command and Control 


(MM-Server) Server. The Malware Mimic Clients will be 
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lightweight software packages that “ride” upon host 


operating systems of the information systems (workstations, 




















etc) of the trainee organization. Bach of these clients 
will be logically connected to a Malware Mimic Server, which 
will deliver commands to the Clients, both individually and 
in the aggregate. Malware Mimic Clients will be capable of 


generating the behaviors of the malware/mal-behavior that we 


wished to emulate. 











For example, as discussed in Chapter , a typical 








behavior in Internet worms is that they scan for adjacent 





vulnerable hosts. In this case, we wish only to mimic the 


behavior of the worm, not the worm itself. The MM-Client, 








when commanded by the MM-Server, could perform a port scan 
of adjacent hosts, just as if it was an actual worm. To the 
observer, the behaviors will be identical, exactly as if a 
worm was propagating across a network when in fact, only the 


behaviors of the preexisting MM-Clients, commanded by the 








MM-Server, will be propagating. In this manner, we greatly 





increase the training’s value (we duplicate the behavior of 








an Internet Worm on the network) without greatly increasing 





the risk to the network (we actually only duplicate the 








behaviors, not the malware itself). Additionally, by using 
this typical client/server architecture, W can take 
advantage of the network property of distribution. The 


trainer, operating the Mimic System, need not be collocated 


with the trainee of the network. 


We can reduce the risk to the network even further. 





MM-Clients will have only narrow windows to perform their 
behaviors before having to reconfirm their commands with the 


MM-Server. This ensures that with a loss of network 
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connectivity, the clients do not continue “head-less,” i.e., 





operating independently of the trainer’s desires. 


Furthermore, using the “two-key” analogy commonly 


employed by ballistic missile systems, we can insert an 





additional server on the local network which serves as a 








local “kill switch.” This second layer of “kill authority” 








will ensure that if emergent local conditions required an 
immediate halt to training that it could be commanded 


without the delay of notifying the trainer. 








In this manner, we solve the problems identified above: 





namely that we create a distributed training system that can 





be consistently and systematically employed across a variety 


of networks, safe enough to use on an operational network, 





all the while delivering the same training value of reacting 





to actual malware used in isolated laboratory environments. 
We can increase training value without concomitant increase 


in risk. 


As discussed, the proposed system will have the 
capability to command observable behaviors and signatures on 


remote hosts. Additionally, it will include the ability for 











the trainer to monitor remote system status, as well as halt 


or continue the execution of behaviors as warranted by the 











operational situation. The only interaction that the 
trainee will have with the system will be to observe 


behaviors and signatures generated by the system and react 





to them. Finally, we propose to include the capability for 
an observer local to the training to have the ability to 
halt the execution of behaviors as local circumstances 


warrant. All of these functions are summarized in Figure 1. 
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Malware Mimic System 


Command Observable 
Behaviors/Signatures 


Monitor System 
Status 


Initialize Server 






Halt/Continue 
Execution Local Kill Authority 


Trainer (Trainee, Trainer, Observer) 


(Localto 
the Trainee) 


Initialize Clients/ 
killSwitch 


Observe Behaviors/ 
Signatures 


Trainee 





Figure 1. Proposed use case. 


F. AN EXAMPLE TRAINING SCENARIO 


Based on the proposed use case of our system, a more 





detailed training scenario may proceed as follows. This 





example assumes that the training would be formal and 


scripted in advance. 


Li Pre-exercise (PRE-EX) 


Prior to commencement of the exercise (COMEX), training 


objectives would be identified and tailored to the 
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particular trainee and training objective by interested 








parties. In this scenario, the trainee would be an 


organization: specifically, the network administrators of 





all the ships of a Navy Carrier Strike Group, underway off 
the coast of Hawaii, performing predeployment training 
exercises. The network environment would be an unclassified 


administrative network between ships of the Strike Group and 





connected to the Global Information Grid. The training 


objectives would be promulgated by the agency responsible 








for the exercise. Additionally, the training scenario would 














be synchronized with other typical predeployment training, 
such as the launching and recovery of aircraft, tactical 
maneuvering and communications of the ships, etc., which 
would be happening simultaneously with the network training. 
The training objective to be covered in this example would 


be that network administrators correctly identify a botnet 





propagating across their network, and report this 








information to the higher echelon of command in accordance 
with previously established procedures. The ships’ Combat 
Systems Training Team (CSTT) would serve as the notional 


“white cell,” i.e., safety observers for the exercise. 


The Malware Mimic Client software would be installed on 
the participating hosts of the strike group network, 
distributed throughout the ships of the group via software 
push. These hosts would consist of the bulk of user 
workstations in the strike group. The software could be 


installed significantly ahead of time, as it would not 





affect the operation of the workstation prior to COMEX, 


remaining effectively dormant in a “sleep state” until the 





prescribed exercise time. Additionally, local to each ship 








of the group, a simple “kill server” would be initialized by 
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the CSTT members that could be used to terminate or freeze 





th xercis should local conditions warrant such action. 





Shortly prior to COMEX, all of the MM-Clients would 








establish a network link to th MM-Server co-located with 





the trainer, in this case a NSA red team physically located 





at Fort Meade, Maryland. The MM-Clients would still not 





have any effect on the user’s workstation. 


2. Commencement of Exercise (COMEX) 





At the commencement of th xercise, the ships of the 





trainee (strike group) network, again, underway off the 


coast of Hawaii, would enter a Combat Systems Trainin 





g 
Environment. This requires notification be passed throughout 
the ships of the group that ship systems were actively being 
used to support training and that actual systems casualties 
would be announced as such. CSTT members would take their 
posts and begin monitoring the system administrators 


(trainees). The red team (trainer) members, again located 





at their facility in Maryland, would log in to the MM- 





Server. They would select from their GUI menu the exercise 





trainee (our notional strike group). Per th xercis 





script, they would instantiate predefined software behaviors 





on the remote workstations of the strike group network. 





These particular modules would consist of behaviors to 
emulate a botnet propagating across the network. As_ such, 


network hosts would begin to scan the network in search of 





other “vulnerable” hosts in order to make network 





connections with them, at which point the scanned hosts 
would begin to scan the network as well. These scans would 
be accompanied by dramatic increases in host network output 


as the hosts simulate the sending of information off the 
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network to a notional botnet command and control server. In 


reality, this would be a coordinated, ever-growing amount of 











relatively benign scans or inert Internet Protocol (IP) 





packets which would cause an increase of network traffic. 


The first indication of the emulated botnet on the 





trainee network would be a slowing of network traffic due to 





the congestion induced by the network scans and generated 





traffic. User logins would take longer due to the slow 





connection to the Active Directory server. Web traffic 





would slow down as well, as DNS queries are also delayed due 


to the congestion. Our trainees, busy with other duties 





assigned to them, would not yet notice the increase of 
network activity, the slowing of network traffic, or that 


the network monitoring systems of their network were 





indicating that the system was being scanned internally. 





As the botnet behavior “propagates” across the hosts of 
the network, the network would continue to slow; e-mail 


traffic would now be affected as the volume of network 








traffic increased. Administrative work on the network 





workstations become affected as e-mail and chat traffic are 





affected. It can be expected that the help desk switchboard 





would “light-up” with complaints from users. Expectantly, 


the system administrators would be notified. 


Upon inspection by the now alerted network 





administrators, the network would be determined to be under 
duress. Network management systems would show alerts 


related to the volume of traffic on the network; protocol 





analyzers would show unusual network connections between 


hosts of the network, and log files would show that systems 


31 


were being probed by internal scanning. The network trouble- 


call logs would be full of complaints by annoyed users. 


The network administrators should correctly identify 








the problem with the network as a botnet-—based attack. In 
accordance with established procedures, network 
administrators would notify the higher echelon that the 
network was infected by a botnet, who would in turn notify 


the NSA red team. Red team members would note that the 





training objective had been completed as the botnet had been 
identified and that the higher echelon had been properly 
notified. The CSTT would have Local Kill Authority. Once 


the training was complete, and in light of the complaints of 





the many users of the network, the CSTT would activate the 








“local kill” function of the system. The MM-Clients, no 





longer receiving the “go ahead” signal from the local kill 
server, would cease scanning and quickly revert to the pre- 


xercise inert state. 





3% Post Exercise (POSTEX) 


POSTEX (following th xercise), the MM-Clients would 





signal to the MM-Server, located in Maryland, that they had 





been stopped. Th server operators (the red team) would 


note that the exercise had been halted locally, and confirm 














via out-of-band communication that th xercis had 
terminated normally. Trainers, assessors, and the trainees 
would then compile their individual notes on th xercise, 
and debrief th xercis via conference call once local 





conditions permitted. 
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G. CONTINUED DISCUSSION OF THE ENVIRONMENT 


This was a both a simple and contrived example of the 








Malware Mimic’s function, but it gives insight into a basic 


architecture from which to discuss, in further detail, the 








different features of the system. In the above example, we 





assume an unclassified, geographically remote, and tactical 








network. In reality, the Malware Mimic should scale well 





enough for administrators of any sized network to _ be 





trained, be it as small as a subset of a tactical network, 





or span multiple Autonomous Systems. The only limitation 


should be the management of the software packages that need 





to be pushed to the individual hosts of the trainee network, 


and limitations inherent in the architecture of the Command 








and Control structure of the Malware Mimic System. 








In our example, we assumed an administrative network, 
but by use of both remote and local kill capability, as well 
as nearly instantaneous “roll-back” of the behaviors to a 
pre-exercise state, the Malware Mimic would be appropriate 


on networks where mission critical services are located. 








Note that in our example, the network behaviors are not 
performed on a network that is isolated in an air-gapped 
laboratory—the intent of the Malware Mimic is to get the 
training out of the lab and classroom, and into the actual 
operating environments of the trainees. Obviously, the more 
critical the systems (risk), the more care in the 


implementation of the emulated behaviors will have to be 





taken (controls/safeguards). 
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H. CONTINUED DISCUSSION OF THE TRAINER 


Trainers on the system need not be geographically 
removed from the training environment. The power of the 


network allows the trainer to be located anywhere on the 








network, ither remot or local. In our example, the 





trainer was in Maryland and the trainee was underway off the 


coast of Hawaii, but in reality, the location of the two 





parties could be any location linked together by the 





network. 


Additionally, trainers need not be formalized, e.g., 





red team members. Assuming that a MM-Server is installed on 


the network and that a properly training operator of the 





server exists, training could be accomplished locally by the 


trainees themselves; that is, the “trainer” and “trainee” 








could be the same person or persons. 


1. Expanded Modules 





In our example, the threat was modeled as a botnet with 





the specific behavior of port scanning emulated. Modules 





could be created that generate th ffects of any category 











of malware discussed in Chapter ‘ Any degree of 





complexity could be undertaken. In our example, only one 








stage of botnet propagation was emulated. Combinations of 
behaviors might be used to emulate specific threats. For 
example, the Malware Mimics on one host could be commanded 
to first scan for vulnerable hosts (behavior one), then 
“appear” on another host (behavior two), then the new host 
begin its scan (behavior three) and make a link with a 


remote host, ostensibly to pipe information offsite 
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(behavior four). This emulates in greater detail and 
complexity the lifecycle of a bot in a botnet. 
We are not limited to the behaviors of bots. The 





Malware Mimics could just 


behaviors 


associated wit 


t as easily be programmed to exhibit 


th a machine 


infected by a virus. 





Mimic-client host-machines could warning messages 


“pop-up” 


to users, asking them to contact system administrators to 


inform them of a mock “system infection.” Host workstations 


could generate virus signatures identifiable by virus 





scanners. Hosts offsite to the network could even be 


programmed to perform the same functions that a malicious 


hacker would perform on the trainee’s network. 














I. CONTINUED DISCUSSION OF THE TRAINEE 

In our example, our trainee was the network 
administration team of an entire Carrier Strike Group. 
Indeed, the “trainee” could be an individual, a team, or 
even an organization. Further, we need not limit ourselves 
to network administrators. The network effects generated by 














the Malware Mimic System, just as the effects of actual 
malware, can affect users, operators, managers, and decision 
makers further removed from the operation of a network. 
Their actions can be assessed using the Malware Mimic 
System, just as those of the network administrator. Consider 
the case involving the havoc created during flight 
operations by the loss of an entire mission critical 
information system; the response of system users or 
administrators in such a situation may have a profound 














the mission as a whole. 





impact on In this way, we can begin 
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to answer a question growing ever more important in modern 


combat operations: “How do the network operations impact the 





entire operational unit?” 





In this chapter, w numerated the participants in 





training, as well as scoped our training environment to that 





of a military network. We proposed an information systems 


approach to the problem and give a detailed example scenario 











of its use. In the following chapter, we give specifics on 
the construction of our solution, as well as the test bed 


used to evaluate its performance. 
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IV. IMPLEMENTATION AND TEST PLATFORM 


A. BACKGROUND 





This chapter will describ th creation of the MM- 





Server and MM-Clients. It will discuss the design features 





built into the software and how the implementation of the 











client-server relationship. In the first half, we will 








discuss the design of the modules that the MM-Clients will 








run, while the second half will discuss the creation of the 





test platform for this experiment. Finally, the 
experiment’s goals will be defined and an explanation of how 
the experiment will be setup to accomplish those goals will 


be provided. 


B. SERVERS AND BOTS 














The architecture outlined in Chapter was largely 








paralleled in our implementation, which includes a single 








command and control server (the MM-Server) that has a one- 





to-many cardinality relationship with our remote client 
nodes (the MM-Clients). For both the MM-Server and the MM- 
Client, we chose Java as the implementation language. The 
primary reason was portability; since we make no assumption 
on the physical architecture of the network, it was prudent 
to select a language that would run on a multitude of 


different platforms, to include Microsoft Windows and Linux. 


The functions provided by our implementation also 

















parallel the architecture outlined in Chapter : A 


trainer gives commands via a user interface to the MM- 





Server, which then commands the individual remote MM-Clients 


Sod 


to perform an externally-observable, network behavior. The 

















MM-Server commands that modules, consisting of the 
behaviors, on the remote MM-Clients be executed; MM-Clients 
receive th instruction to execut the module, and execute 





the preprogrammed function that performs the commanded 


behavior. 


1. Server Construction 





The MM-Server consists of six Java classes, including 





the data structure that maintains information on the client 
nodes of which the server is aware and the user interface. 
The MM-Server functions similarly to a Web server in that it 


spawns handlers to handle incoming connections from the MM- 





Clients. The server is multi-threaded to allow for multiple 





simultaneous Transport Control Protocol (TCP) connections 





and full-duplex communications with its MM-Clients. 





The data structure utilized to track connections 





between the server and remot MM-Clients is a Java 


Synchronized Sorted Map. The Synchronized Sorted Map offers 





built-in handling for the multi-threaded nvironment, and 


its use simplified the coding requirements significantly, 





i.e., TE inherently handled issues of thread 
synchronization. For larger (in terms of numbers of MM- 
Clients) implementations, a database, such as MySQL should 
be used, though it will come at the cost of added 


complexity. 





In order to keep implementation as simple as possible 


(with an eye on scalability), the data structure maintains a 





traditional “mail box” model for MM-Client/Server 








communications; within the data structure, MM-Clients have 
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inboxes (orders) and status boxes. Inboxes are set only by 


the server; status boxes are first initialized by the 








server, and then written to exclusively by the MM-Client. In 
this manner, synchronization issues with multiple MM-Clients 
are avoided. The data structure is keyed uniquely by a 
concatenation of the host node’s machine name and a node 
name given at invocation. The data structure also includes 


a field for explicitly declaring the exercise in which the 








node is participating, e.g., a specific strike group 


COMP TUEX. 


2. Client Construction 





On initialization, MM-Clients attempt to establish a 








TCP connection with th remot server whose socket pair 
address is declared in the invoking command-line parameters. 


Tee. eh remot server is not available, the MM-Client will 











continue to attempt contact every 10 seconds until the 


connection succeeds. 


Once the connection is established, the MM-Client 





requests the contents of its “inbox” from th MM-Server, 
then calls the appropriate module based on the response. 


Modules contain preprogrammed sets of behaviors. Currently, 











ther ar thr modules of behaviors. Module Zero is an 


instruction for the MM-Client to cease commanded behaviors, 











and to return to an idle state. In the idle state, the MM-— 


Client continues to request its inbox contents from the MM- 





Sever at five-second intervals. Module One commands five 





icmp “pings” of the MM-Server. This module is used for 


connection troubleshooting. Module Two commands a “SYN 





scan” of 10 random ports of the MM-Server. This module is 


use to demonstrate the feasibility of a remotely-commanded, 
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externally observable, network behavior from the MM-Client. 


This behavior is intentionally modeled on the scans 





performed by the bots of a botnet, as discussed in Chapter 














Module Two’s complex scanning behavior is not native to 
Linux or to any of the Microsoft Operating Systems. For 
these scans, we utilized Salvatore Sanfilippo’s “hping” 


software, available at www.hping.org under the GNU General 





Public License v2. Use of hping on Microsoft Windows 


platforms additionally requires the use of CACE Technology’s 





WinPcap library (specifically, we used version 4.1.0.2001), 
whose license is currently available for viewing at 


www.winpcap.org/misc/copyright.htm. Additionally, we had 





problems using hping version 3 on XP; reverting to version 2 
was required. This version is currently available at 


http://sourceforge.net/projects/sectools/. 





Unfortunately, the use of hping clients on Linux hosts 
requires the use of raw sockets, which are not available 


without administrator privilege. This can be overcome by 





appending the command for hping to the sudoers list of the 


Linux client, e.g., %admin ALL = NOPASSWD: /sbin/hping3. 





MM-Clients are not multi-threaded. This is an 


intentional design feature incorporated for safety; MM- 





Clients only execute limited amounts of code before blocking 


for a continuation confirmation from the MM-Server, and in 





the future, a “kill server” on the local network. Tf at any 





point MM-Client connection with th MM-Server is lost, it 
ceases any commanded behaviors and reverts back to its 


initialization behavior, i.e., entering an “idle” loop, 








attempting to reconnect every ten seconds until successful. 
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3. Communication Protocol 








The communication protocol between the MM-Server and 


the MM-Client is shown in the flow chart shown in figure 








two. The flow chart assumes that th MM-Server has a 





preexisting session established between one or more MM- 





Clients. When first initialized, the MM-Clients are in an 





idle state, as discussed above. When the trainer inputs a 
module command to be executed into the user interface, that 


command is written by the server to the inbox of the MM- 





Client. The MM-Client periodically (currently set to every 
five seconds) retrieves its inbox, then confirms the command 


with the “local kill” server. (The kill-switch feature is 








not yet implemented.) If it receives a “continue,” the MM-— 














Client updates its status on the MM-Server, and executes on 








iteration of the commanded behavior. At this point, it 


loops back to checking its inbox, and continues as above. 


Behavior iterations are, and shall be, kept at an 





acceptably small duration, in order to allow the trainer or 





local kill server to cease behaviors in a reasonable amount 











of time, currently set to 10 seconds. As above, the MM 


Client blocks while checking its remote inbox or confirming 





its command with the local kill server. If a halt is 





received in either situation, the MM-Client ceases 





behaviors, and reverts to an idle state. 
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Assumes previously 
established session 
between MM-Server and 





Trainer inputs Run 
Module X command at 
Server Console 


one or more MM-Clients. 








Server sets 
MMCLIENT Inbox(es) 
to MOD_X 


MMCLIENT checks 
inbox 


MMCLIENT reads 
MOD_X, sends 
STATUS=MOD_X 
to Local Kill Server 


> [Not IRO CONTINUE] 


ONTINUE] 






MMCLIENT stops 
running MOD X 







MMCLIENT sends 
STATUS=MODx to Server, 
runs 1 iteration of MOD xX, 






MMCLIENT sends 
STATUS=STOPPED 


MMCLIENT checks 
inbox 





[INBOX EQUALS MODXx] 





[NOT INBOX 
EQUALS MODX] 


[ NOT INBOX 


[ INBOX EQUALS HALT ] 






QUALS HALT] 


Figure 2. Communication protocol flow diagram. 
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The communications between the MM-Server and the MM-— 
Client are passed in clear text, vice the host of other 
message passing facilities available in Java. The reason 
for this design decision was two-fold. First, the observable 


plain-text is much easier to troubleshoot. Second, the 











client-server session could utilize port 80, encapsulating 
the commands in Hypertext Markup Language, and in this way, 


be less likely to be flagged by any intrusion detection 











system that might be at a point between the MM-Server and 





MM-Client. This encapsulation feature is not yet implemented 


in the code. 


4. Graphical User Interface for MM-Server 


It was desired for this program to have a Graphical 











User Interface (GUI) as well. Once the MM-Server is adopted 


and is utilized to control hundreds to thousands of 








computers, then a GUI may be essential to ease the 


administrative tasks of monitoring the status of the MM- 





Clients, and controlling their behavior by issuing tasks to 





individual or groups of MM-Clients on the network. 








The GUI was designed using the NetBeans Integrated 











Development Environment (IDE) 6.9.1. NetBeans provides an 





efficient and user-friendly design tool for developing rapid 





prototypes of graphical user interfaces. The tool also does 
a great deal of the coding of the layout; as the user 
establishes the look-and-feel of the interface by 


instantiating the frames, panes, and the locations of the 





fields, buttons, and labels, the coding is done in the 


background for the layout and format of all these items. 





This relieves the developer of much of the tedious tasks 
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associated with layout development and enables him to remain 


focused on the functionality to be provided. 





The initial GUI design contains three different views: 








an icon-based view, a tree-based (or folder) view, and a 





tabular view. The tr based view was implemented in this 





thesis, while the icon and tabular views are left for 





further study. The tr based view is very similar to the 





file management tools in Windows, Macintosh, and Linux 


environments. 


Fach MM-Client is a node within a tree. By clicking on 





those nodes, the status of that MM-Client is displayed along 








with the ability to give new orders to the MM-Client. In 





time, the ability to select multiple MM-Clients and submit a 


batch order to the group will be implemented. Such a 





capability will enhance the controller’s ability to rapidly 





manage the training or evaluation scenarios. 


Cc. BUILDING THE TEST PLATFORM 





For our test, we built a small network of 20 nodes. In 
a real case of deployment, since our system is envisioned to 


be running as a distributed system, the MM-client software 





should be installed on many, if not all, devices in an 


organization connected to a MM-server. Therefore, it must 





be shown that th MM-server can handle the communication 


between multiple networked devices and that there would be a 








minimal delay from the time the command is given to a subset 
of MM-clients to the actual execution of that command. This 
delay should be dominated by the network-—dependent 


characteristics of the messages, such as transmission, 
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propagation, and queuing delays, and not their processing by 


the MM-Server of MM-Client applications. 


We designed a test platform based on virtualization for 





evaluating the MM-server and MM-clients. This test 





environment allows for greater flexibility in the types of 





operating systems utilized, minimal footprint taken up by 
equipment and cable runs, and for general expansion of the 


number of MM-clients run. 


VMware’s products were utilized in our thesis, in 


particular VMware View and VMware Workstation. These 





products will hereafter be referred to as a VMware Player. 
VMware allows many different Operating Systems to run as 


Virtual Machines on a single host platform. A Virtual 





Machine is essentially a complete, logical, computing 





machine. The user perceives the VM (Virtual Machine) as an 
entire computer solely running a particular Operating System 


and software. The VM is actually just another program being 





run by the host computer’s Operating System (OS) with memory 


requirements. The file manager installed with the host OS 





allocates a large file on the hard drive which is accessed 
as a virtual disk from the VM. The VMware Player 


virtualization layer maps the actual physical resources of 








the host computer to the virtual machine’s resources. 





Device driver support is inherited from the host OS. As 





such, activity inside the VM is handled by the host OS, 


device drivers, or directly by the hardware. 





The VMware View or VMware Workstation program serves as 
a translator between the virtualized OS and the host 


computer. VMware translates desired commands into commands 





that must be scheduled and performed by the host’s processor 
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and other resources. This translator is referred to as the 
hypervisor. A hypervisor is a piece of software that is 


closely tied to the host OS or to the host computer’s 





hardware. Each VM is entirely encapsulated and must make 





all processor, resource, and device driver calls through 


this hypervisor. The hypervisor is in charge of 








coordinating all of these requests to the host OS or host 


computing machinery. 


The host computer must have adequate hard drive space 





for a large file that will contain the VM’s virtualized hard 





drive and sufficiently large physical memory (RAM) to be 





allocated to the VM’s running process. The greater the 





number of virtualized hosts on a given platform the greater 
the demands for hard-drive space and RAM. A common and 
current computer can run the host OS and one or two VMs 


Simultaneously. To do more requires a much more powerful 





computer. 


Virtualization can b leveraged further—instead of 








using desktop computers, more powerful servers were 





utilized. The test platform was built utilizing two Dell 





PowerEdge 2950 Servers (eight 32-bit processors, 4 GB of 








main-memory (RAM), and 131 GB hard drive storage). These 
servers provide the capacity and performance required to run 
more than just a few VMs at once. Similar to the VMware 


View/Workstation program, a hypervisor is required to 








coordinat th us of the hardware’s resources by the 
running VMs. VMware vSphere Hypervisor is a rebranding of 
what was previously known as VMware ESX and ESXi. The 
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vSphere Hypervisor runs on the “bare metal,” meaning that no 
host OS must be installed on the server in order to support 


the hypervisor. 





Besides the two physical servers, a Dell Latitude E6510 








laptop with an Intel i7 Core, 64-bit processor, and 8 GB of 
RAM was required. The laptop was our tool for creating VMs, 
converting them for use with the hypervisor, and 
transferring them to the physical servers. Once the VMs 
were transferred, the laptop was our means for controlling 
which VMs were active on the server, and for accessing 
inside each individual VM as if it were a separate computer 


awaiting our commands. 


VMware View allowed us to create the VMs that would be 
installed onto the servers. Using the iso images of the 
Ubuntu 10.10, Ubuntu Server 10.10, and Windows XP Service 


Pack (SP) 3 Operating Systems, we created three individual 





VMs. Once the installation was complete, each VM was 
accessed and the additional software was installed: Java 
Runtime Environment, MM-Client, MM-Server, Wireshark, and 


hping. 


VMware Converter allowed us to transport the VMs from 
the laptop to the servers. VMware Converter can take many 
different VM types and create a VM that is compatible with 
the hypervisor. These VM types include other VMware-based 
VM, Microsoft VMs, and other third party images, such as 
Norton Ghost images. The VMs and/or images must be loaded 
onto the servers hosting the hypervisor with VMware 


Converter. Failure to do so will result in VMs that do not 





work and that may possibly corrupt VMs previously loaded 


onto the server. 
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Once the VMs are loaded via the VMware Converter, the 
last required piece of software is used: VMware vSphere 
Client. This software is the management that that allows us 
to coordinate the actions of all the loaded VMs on the 
servers. Through the vSphere Client, all of the loaded VMs 
can be accessed. Similar to the VMware View program, these 
VMs can be started, stopped, suspended, or restarted. Once 
running, a console window can be accessed which allows the 
user to fully utilize the hosting system just as if it was 
on the controlling laptop. Furthermore, vSphere Client can 
provide statistics on each individual running VM or the 
entire physical server. Figure three shows the physical 
layout of the test platform along with the installed 


software. 





Figure 3. Physical test bed configuration. 
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D. EXPERIMENT DESIGN 


The overarching goal of th xperiment was to have a 








Single running MM-Server with approximately 20 MM-Clients 
connected to it. Once all the machines were connected, we 
wished to show that the machines could be controlled in a 
timely fashion and that MM-Clients would generate an 


externally observable network behavior. 





Another goal was to verify the MM-Server and MM-Client 


software could work on Windows and Linux environments. Most 














of the computers used by DoD commands are running Microsoft 


OS’s: primarily Windows XP. For example, the Navy and 











Marine Corps Infrastructure and the shipboard IT-21 program 





also typically use Windows XP. Other OS’s used within the 











DoD are Linux or Solaris based. It was mandatory that we 





verify that our code worked on the common platforms within 














the DoD and to prove the MM-Client’s portability between the 


various OS’s. 


One obstacle identified in the setup of the experiment 








was the licensing limitations of the VMware vSphere Client. 


The VMware vSphere Client license is limited to ten 





activated VMs at any one time. Due to licensing 
restrictions, utilizing two servers, only twenty VMs can be 
running simultaneously. The physical servers can have more 
VMs installed, but only ten of those installed VMs can be 
activated at once. One VM was configured as the MM-Server. 


The other 19 ran the MM-Client software. 








1. Operating Systems and Software Utilized 
Each host, less one, was running th MM-Client 
software. One client was designated as the MM-Server; it 
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ran th MM-Server software. For each to run, the Java 
Runtime Environment (JRE) was installed on each machine. 


The JRE was downloaded from Java’s website for the Windows 





XP SP3 VMs. The package openjdk-6-jre-headless was 





downloaded and installed on the Ubuntu and Ubuntu Server 
images. The operating systems utilized on the VMs were 
Microsoft Windows XP Service Pack (SP) 3, with all updates 
installed; Ubuntu 10.10; and Ubuntu Server 10.10. Section 
B.2 above has information about the software that was 


utilized for each of the modules. Again, Microsoft XP was 











selected, as it runs upon th preponderanc of DoD 





workstations. 





The MM-Server was run on an Ubuntu host VM. The MM-— 
Server also served as the network monitor; towards this, MM- 


Client nodes were configured to direct network behaviors at 








th MM-Server. Utilizing th MM-Server’s Module 0 (the 
initial and idle state for all of the MM-Clients), the MM- 








Client query the mailbox at the MM-Server for commands. In 





Module 1, the MM-Client sends a series of ICMP pings to the 








MM-Server. In Module 2, the MM-Client utilizes performs a 


SYN-scan of the MM-Server. All of the traffic was destined 





for th MM-Server whose computer would also be running 


Wireshark, a protocol analyzer. Finally, the MM-Server was 








also configured as a Dynamic Host Configuration Protocol 


(DHCP) server so that all of the VMs would not have to be 








assigned static IP addresses during test-bed startup. 








It was desired for all traffic to be targeted to the 





MM-Server so that all communications and results of the 





running modules could be captured and analyzed. The 








experiment’s goals were verification that the system worked, 
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verification of the timeliness with which the MM-Clients 
obeyed the commands, verification of correct behaviors of 


the MM-Clients running the modules. 





Specifically, the test bed was set up as such: 
e Command and Control Server 
*" Ubuntu Operating System 


=» MM-Server 





=™ DHCP Server 
=» Wireshark 
e Nineteen (19) Hosts 


=" MM-Client receiving commands from the MM- 


Server 








" Assigned IP addresses from the DHCP server 








" Five (5) hosts running Ubuntu Desktop OS 


" Five (5) hosts running Win XP SP3 OS 








*™" Nine (9) hosts running Ubuntu Server OS 





This is represented graphically in figure four. 
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WinXP SP3 WinXP SP3 WinXP SP3 WinXP SP3 WinXP SP3 
MM-CLIENT MM-CLIENT MM-CLIENT MM-CLIENT MM-CLIENT 


10.19.61.123 


Ubuntu 
MM-SERVER 
DHCP Server 


Wireshark D D> 


10.19.61.21 10.19.61.22 10.19.61.23 10.19.61.24 10.19.61.25 
Ubuntu Server Ubuntu Server Ubuntu Server Ubuntu Server Ubuntu Server 
MM-CLIENT MM-CLIENT MM-CLIENT MM-CLIENT = MM-CLIENT 


Se LY HL 


10.19.61.26 10.19.61.27 10.19.61.28 10.19.61.29 
Ubuntu Server Ubuntu Server Ubuntu Server Ubuntu Server 
MM-CLIENT MM-CLIENT MM-CLIENT MM-CLIENT 





Figure 4. Virtual test bed configuration. 


E. RUNNING THE EXPERIMENT 





The VM that hosts the MM-Server, DHCP server, and 





Wireshark must be started first. Then, all of the other VMs 
may be started and the MM-Client software executed. While 
the MM-Clients connect to the MM-Server, status messages on 


the MM-Clients and MM-Server should be monitored to verify 





the connection made between the MM-Server and each MM- 
Client. Furthermore, Wireshark can be used to monitor the 


externally observable network behavior of MM-Clients 








querying their mailbox on the MM-Server for updated 


commands. 
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For purpose of our experiment, once all VMs and 
programs were started, we would verify that all programs 


respond to the changes of the requested running module by 











the MM-Server. Data would be analyzed using Wireshark to 





examine the change in network traffic directed at the MM- 


Server. Once all changes between module states zero to two 





wer verified, ach module would be run for up to five 


minutes to allow the system to reach a_e steady-state. 





Finally, the MM-Server would be stopped and Wireshark used 
to assess the changes in behavior of the MM-Clients as they 


changed from a running module to a failsafe state. 


During all of the above, performance data would be 





captured about the server, to include CPU utilization, 


memory allocation, disk activity, network capacity used, and 





other statistics. The purpose of this data collection was 
to support an analysis of the strain under which the two 


servers are operating during this test. 


The overarching purpose of this experiment would be to 





verify the system functions as designed. It would also be 
to verify that the MM-Server could handle multiple 


connections and that there would be timely changes in 








requested behavior by the MM-Clients. Finally, it would 











assess whether there was any strain upon the MM-Server or 





the physical servers themselves due to operation all of the 





virtual machines (this would indicate a scalability issue 





for a small deployment venue). As such, the experiment would 
serve to establish a benchmark for the performance of the 


Malware-Mimic System in a benign environment. 
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F. SUMMARY 


This chapter discussed the system infrastructure 


consisting of the command and control MM-Server and the 





remot MM-Clients. The protocol’s design was examined, 


specifically in relation to how the MM-Clients would receive 








the orders from the MM-Server. The protocol was designed 
with safety as the paramount feature. The MM-Clients must 
have guidance in order to start the modules. That guidance 


must persist for a new iteration of behavior to occur. 


The test platform and the general design of the 


xperiment were discussed. The test platform relies heavily 





upon virtualization. Virtualization allows for a varying 








number of systems to be activated, a variety of operating 


systems that can be utilized, and various network 





configurations, so that the MM-Server and MM-Client software 











can be fully vetted. It also forms a platform for further 








expansion in the formulation and testing of new modules, new 
operating systems, and more complex networks. The next 


chapter will provide the results of the experiment. 
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V. RESULTS 


A. BACKGROUND 


This section provides details about the implementation, 








as well as the results of th xperiment delineated in 





Chapter IV. The results demonstrated the viability of this 





novel training and evaluation tool. The protocol functioned 








as it was designed, with feedback between the MM-Server and 


the MM-Clients. The safety features wer adequat in 





restoring the MM-Clients to their failsafe state during 








interruptions in network connections with their respectiv 
MM-Sever. Observable network traffic was positively 


identified which can fFulfacLi training and analysis 





objectives. Finally, it was verified that the test platform 
is a suitable testing environment prior to deployment on a 


live network. 





B. SETUP 
The two servers began th xperiment in steady state 
with all VMs shutdown. On the laptop, we connected to each 








Physical Server utilizing vSphere. The Ubuntu VM that would 








run the MM-Server on Physical Server 2 was the first VM 








started. This was needed becaus that VM had a fixed IP 
address (10.19.61.123) and also hosted the DHCP server that 














would allocate IP addresses to all of the other VMs as they 





started up. Once the DHCP service was operating, all 





nineteen of the other VMs were started. Figure 5 shows 





which types of VMs were running along with their respectiv 








IP addresses on each physical server. 
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Figure 5. Physical server IP addresses/type/names. 











The specific IP addresses of the Physical Servers were 











not relevant for the experiment. The IP addresses 
facilitated connections via the laptop running the VMware 
vSphere Client software in order to control all of the VMs 
running on the servers. The controlling laptop was given an 


IP address of 10.19.61.235. 





Physical Server 1 had five MM-Clients running on the 





Windows XP Professional Service Pack 3 (WINXP SP3) Operating 


System VMs, and five MM-Clients running on the Ubuntu 10.10 
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Operating System VMs. Physical Server 2 had nine MM- 
Clients, one per Ubuntu Server 10.10 VM, and the one MM-— 


Server running on the Ubuntu 10.10 VM. All MM-Clients 








connected to the MM-Server at the IP address 10.19.61.123. 











The IP addresses were required so that the Wireshark packet 





capture could be analyzed in order to ensure all of the MM- 
Clients were executing the correct module and to get a 
measurement on how quickly each responded to the change in 


commands. 


Cc. TIMELINE 


Physical Laptop (10.19.61.235) connected to both running Physical Servers 1 and 2 

Server 2 (10.19.61.237): toggled on VM 10.19.61.123 (the Ubuntu VM that has MM-Server) 

Server 2 (.237) > Ubuntu VM up (.123), Wireshark and DHCP server up 

Server 2 (.237): toggled on the nine other Ubuntu Server OS VMs 

Server 1 (.236): toggled on the five WinXP and five Ubuntu VMs 

Server 2 (.237) > Ubuntu OS VM (.123) started MM-Server a for incoming connections on port 30000 


[se __}urzs-125 [server 2 (237) >all Ubuntu Server OS VMsup, all MM-Clients connected toMM-Sever =| 
| HK |:28-2:35PM__ [Server 1 (.236) >all WinXP and Ubuntu VMs up, all MM-ClientsconnectedtoMM-Server | 
| tt |aa5pM__[MM-Server/(.123) showsall nineteen MM-Clientsconnected 
: MM- ers “123) issues run MOD_1:ALL command 

MM-Server (.123) issues run MOD_2:ALL command 

MMM-Server (.123) issues run MOD_0:ALL command 

MN-Server (.123) issues run MOD_2:ALL command 

Turn off MM-Server, verify all Clients return to MOD_0 behavior 

Server 1 (.236): Shutdown all VMs 


ee 1:59-2:02PM _ [Server 2 (.236): Shutdown all VMs 






































Figure 6. Experiment Timeline of Events. 


The timeline (Figure 6) shows the order and times of 


specific events during the entire experiment. This helped 





us correlate the information in all of the packets displayed 
in Wireshark with the events that occurred. Furthermore, 


this timeline is meant to be used in conjunction with 





Figures 8 and 9 (showing CPU utilization per physical 


server). The alphabetical labels on Figures 8 and 9 








correspond to the same labels in the left hand column in the 


timeline shown in Figure 6. 
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D. DISCUSSION OF RESULTS 


Overall, th ntir xperiment verified system 

















performance per the architecture set forth in Chapter 


All VMs functioned as configured, and all MM-Clients 





connected to the MM-Server performed the desired actions and 





responded to the changes in commands in less than ten 





seconds. Th MM-Server had no dropped packets on the 











Network Interface Card and Wireshark showed all of the 


traffic between the MM-Clients and the MM-Server. 





1. Results for MM-Server and MM-Clients 





Th MM-Server performed according to specification. 


All MM-Clients connected to the MM-Server as designed. The 





Ubuntu VM hosting the MM-Server operated with no degradation 


in performance under the load of the nineteen TCP sessions 





of the MM-Clients. The Linux “top” command showed that the 


Java process of the MM-Server utilized approximately 0.3% of 





the CPU time. It also showed that the percent of memory 
utilized by the same process started at 2.5% when no MM-— 


Clients were connected and only grew to 2.9% when all 





nineteen MM-Clients were connected. 


An example of the time it takes to transition between 





states for the MM-Client is given below. Since the MM- 


Server does not actively send a command to a MM-Client, the 





responsiveness between a typed command at the MM-Server and 





the MM-Client receiving that command, updating the MM- 


Client’s status and then executing that command is somewhat 








slower than it could be. However, as seen in Figure 7, it 


takes approximately 5-6 seconds for a MM-Client to cease the 





current running module, access and process the new order 
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from its mailbox in the MM-Server, update its status with 
the MM-Server and begin exhibiting the correct behavior of 
the newly ordered module. This delay can be attributed to 


many different processes: physical, programmable, and 





virtual. The physical realm deals with the actual signal 
propagating through the physical wires and switch. Within 


the programs, the command is placed within the MM-Client’s 





inbox on the MM-Server and there is a delay depending on 





when the MM-Client “checks back in” with the MM-Server 


following a single iteration of the current ordered module. 





Finally, since there are two physical servers running twenty 


VMs, there are additional delays due to the non- 





deterministic scheduling of the VMs, as well as the overhead 


of the hypervisor. 


Time From |To [Packet ID__[Command/Response_ [Comment 
13:35:51.218740 |.67 123 113649 —_—«|GETINBOX MM-Client querying INBOX 


MM-Server responds: your INBOX command 
13:35:53.256175 |.123 67 13653 INITIALIZED says INITIALIZED (continue running MOD_0) 
13:35:56.218650 |.67 123 13803 _| GETINBOX MM-Client querying INBOX 


pscasiseseuez [129 [or _}13807_|woo_1_|uw-Serverresponds:run MOD_L(pingme) _| 
136: MM-Client pings MM-Server - correct behavior for MOD_1 

MM-Client running MOD _1 

as sie ES a iad Last 5 Pings of MOD_1, now check inbox 

13:40:09.865639 |.67 123 [2ss60_—|GETINBOX Ss [MM-ClientqueryingINBOX 

13:40:09.866071|.123 [67 f2ss6a_— |MoD_2_ SS [MM-Server changes command torun MOD_2(SYN Scan) _| 

13:40:14:856811 25744 

13:40:15.143224 25755 

MM-Client running MOD_2 

Last SYN scans of MOD_2, now check inbox 

MM-Client querying INBOX 

13:45:20.402246 ier [x23 —[sasos [srarus-M0_ 0 MM-Cllent:eceved command to ran MOD, 0] 


























Figure 7. Packet Capture between MM-Client and MM-Server. 





The MM-Clients were designed for safety and the ability 


to be controlled remotely. Figure 7 is a sample of the 





latter, utilizing a Wireshark packet capture between the MM 
Client hosted on the WINXP_O8_Client (10.19.61.67) and MM-— 
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Server (10.19.61.123). To test the former, th xperiment 





ended with an abrupt termination of the MM-Server with all 





nineteen MM-Clients having active TCP sessions. The ensuing 


network traffic from the MM-Clients to the host which had 





been previously running MM-Server at 10.19.61.123 was 





captured by Wireshark. Within seven seconds, all of the MM- 


Clients that were running Module 2 entered their failsafe 





behavior. All MM-Clients performed as expected, which 


suggests that the built-in safety mechanism performed as 





planned. That is, if the MM-Server is no longer present to 


give orders, the MM-Clients will terminate all previous 











behaviors, revert to a benign, failsafe mode, and attempt to 





reestablish a connection with the MM-Server. 
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2. Results for the Physical Servers 


Physical Server 1 - 10.19.61.236 
CPU/Real-time, 2/26/2011 1:03:16 PM - 2/26/2011 2:03:16 PM - localhost.localdomain 


100 20000 
Ta 15000 
| 


qua2108d 


50 | 10000 





25 \j Hi i i j |} S000 
‘mall os | MAN Ii 
1 AN a Pe 
i! I WV N iH vi 
|] LY A ay Wag) VY 
0 i 1 i t 1 0 
1:05 PM 1:15 PM 1:25 PM 1:35 PM 1:45 PM 1:55 PM 
Time [AlB[clE] [H] [1[y] — [k] [mM] [N] [0] 
Performance Chart Legend 
Key Object Measurement Rollup Units 
ay 0 CPU Usage average Percent 
im 1 CPU Usage average Percent 
i | 2 CPU Usage average Percent 
B 3 CPU Usage average Percent 
B 4 CPU Usage average Percent 
H 5 CPU Usage average Percent 
i} 6 CPU Usage average Percent 
H 7 CPU Usage average Percent 
Oo localhost.localdomain CPU Usage in MHz average MHz 
i | localhost.localdomain CPU Usage average Percent 


Figure 8. CPU Utilization of Physical Server #1. 
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Physical Server 2 - 10.19.61.237 
CPU /Real-time, 2/26/2011 1:06:07 PM - 2/26/2011 2:06:07 PM - localhost.localdomain 
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Performance Chart Legend 
Key Object Measurement Rollup Units 
| | CPU Usage average Percent 
O 1 CPU Usage average Percent 
O 2 CPU Usage average Percent 
| 3 CPU Usage average Percent 
a 4 CPU Usage average Percent 
e] 5 CPU Usage average Percent 
| | 6 CPU Usage average Percent 
Es] 7 CPU Usage average Percent 
B localhost.localdomain CPU Usage in MHz average MHz 
|| localhost.localdomain CPU Usage average Percent 


Figure 9. CPU Utilization of Physical Server #2. 





The performance of physical servers one and two (IP 
addresses (10.19.61.236 and 10.19.61.237, respectively) 
running the hypervisor and all of the  VMs-~ matched 
expectations. According to the CPU utilization graphs 


(Figures 8 and 9), the large spikes in CPU utilization were 
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the actual starting and stopping of the VMs (points D and 
E). The other large spikes occurred at points G and H, when 
all of the MM-Client software and Java Runtime Environment 


was activated. 


After the MM-Clients were started and connected to the 





MM-Server, CPU utilization of the actual physical servers 





was negligible. The initialization and idle state (Module 








0) had the MM-Clients communicate onc very ten seconds to 





th MM-Server in order to check for messages in their 





respectiv queu (Module O began at Labels I and L in 





Figures 8 and 9). This activity had a negligible effect on 
the CPU, even though the CPU is “serving” both the MM-Server 











and the MM-Client entities. Module 1 is not CPU-intensive, 





calling only a series of five pings back to the MM-Server 





per MM-Client instantiation for the module cycle of ten 


seconds (Module 1 began at Label J in Figures 8 and 9). 





Module 2 activated another process, hping, in order to 
perform a SYN scan of the MM-Server. This shows an increase 
of about 15-20% CPU utilization on both physical servers 


(Module 2 began at Label K in Figures 8 and 9). The 





physical servers handled the swapping between the ten VMs 








and the network traffic between the MM-Server and MM-Clients 





as expected. 
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Physical Server 1 - 10.19.61.236 
Network/ Real-time, 2/26/2011 1:03:41 PM - 2/26/2011 2:03:41 PM - localhost.localdomain 


sdg» 
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3000 

2000 

1000 

—_—_ 
0 i i 1 i I 
1:05 PM 1:15 PM 1:25 PM 1:35 PM 1:45 PM 1:55 PM 
Time 

Performance Chart Legend 
Key Object Measurement Rollup Units 
O localhost.localdomain Network Data Receive Rate average KBps 
Oo vmnico Network Data Receive Rate average KBps 
Bl localhost.localdomain Network Usage average KBps 
| | localhost.localdomain Network Data Transmit Rate average KBps 
O vmnico Network Data Transmit Rate average KBps 


Figure 10. Network Utilization of Physical Server #1. 
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Physical Server 2 - 10.19.61.237 


Network/ Real-time, 2/26/2011 1:05:42 PM - 2/26/2011 2:05:42 PM - localhost.localdomain 
900 
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Time 
Performance Chart Legend 
Key Object Measurement Rollup Units 
my localhost.localdomain Network Data Receive Rate average KBps 
B vmnicO Network Data Receive Rate average KBps 
I} localhost.localdomain Network Usage average KBps 
|| localhost.localdomain Network Data Transmit Rate average KBps 
i vmnicO Network Data Transmit Rate average KBps 
Figure 11. Network utilization of physical server #2. 


Hard disk activity of the physical servers was 
negligible. Main memory (RAM) usage by each of the physical 


servers was as expected when running all of the VMs: 





approximately half of the onboard memory was utilized. Each 
physical server had 4 GB of main memory. Upon startup of 


all the VMs, memory peaked to almost full utilization. Once 

















all the VMs were fully booted up, logged into, and the MM- 


Server and all MM-Clients activated, memory usage was 
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approximately 25-50% in steady state. It is to be noted 
that for future work, if more VMs are to be run 
concurrently, the onboard memory should be increased to 8 or 


16 GB. 


Network activity of the physical servers due to the 
Malware Mimic system is harder to isolate and assess. As 


seen in Figures 10 and 11, overall network traffic was well 





within the Gigabyte Ethernet capability of the server 








Network Interface Cards and the switch. However, there are 


some large spikes in network traffic that must be explained. 





In Figure 10, the network traffic for Physical Server Il 
(.236), there were large spikes of approximately 2-3 


megabytes per second (MBps) at the setup and shutdown of the 





experiment and it was mostly steady around 200 kilobytes per 
second (KBps) during the actual running of the different MM- 
Client modules. The large spikes of 2-3 Mbps were due to 


the external connection of the laptop that contained the 





vSphere Client software. Through vSphere, we utilized the 
remote console window to access every VM. Once we were 


logged in to each VM and the MM-Client software was started, 





the now unneeded VM remote consoles were closed. At the 








end of th xperiment, the VMs wer remotely logged into 
again, in order to stop the MM-Client software and shutdown 


the VMs. The vSphere Client allowed a remote console 





window, giving full access to each VM as if sitting at a 





normal desktop computer. All of these live video feeds of 





the running VM to our remote console were sent over the 





network connection from the Physical Servers to the laptop. 
This explains the large spikes at the beginning and end of 


the experiment as seen in Figure 10. 
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The network activity of Physical Server #2 (.237), 


shown in Figure 11 was similar to that of Physical Server 











#1, with the large 900-KBps spike at the startup of all the 








VMs. This is less because the Physical Server #2 has nine 
Ubuntu Server OS VMs running. The Ubuntu Server OS is 
accessed from a command prompt. This interface was text- 





based, unlike the graphical interfaces of the Ubuntu Desktop 





OS and WinXP OS. Therefore, the amount of information sent 


over the network to our remote console was significantly 





less than the graphical environments of Ubuntu and Windows 





XP. However, during the period when the different MM-Client 








modules were being accessed, Physical Server #2 has about 


twice the network activity. This can partly be explained by 








the fact that the Ubuntu OS VM (.123), with the MM-Server 


software on Physical Server #2, was the only remote console 





utilized to control all of the MM-Clients. Therefore, th 





live feed from that VM was sent over the network to the 





external laptop in order to control the flow of the 


experiment. 


To isolate the network traffic resulting solely from 
the VMs, Wireshark statistics from the Ubuntu VM running the 
MM-Server was used. Wireshark provided an input/output 


graph of the amount of packets (or bytes) per unit time. 





The output was configured for bytes per second. During the 
test run, with all MM-Clients running Module 0 (idle state), 


traffic to and from the MM-Server was 0.5-3 KBps. When all 








MM-Clients were running Module 1 (ping), traffic was 1.5-8 
KBps. When all MM-Clients were running Module 2 (SYN scan), 
traffic was 4.5-8 KBps. Comparing these numbers to the 


graphs in Figures 10 and 11, we discovered that there is a 





Significant amount of network traffic overhead for the 
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virtualization of network traffic as well as the live video 








feed for the remote console capability. In comparison, if 





th MM-Server and MM-Clients were utilized on a live, 
operational network, the resulting network activity of 0.5-8 


KBps would be relatively insignificant compared to the 10, 








100 or 1000 MBps capacity of today’s networks. 








E. SUMMARY 
Th xperiment demonstrated that our system performed 
as designed. All of the test goals were accomplished and 


there was an observable validation for each portion of the 





experiment. This included the most important of the goals: 








demonstrating the ability to control the MM-Clients in a 
timely manner. The MM-Clients were all responsive in 


changing to the ordered module, and when communication to 





th MM-Server was severed, all MM-Clients ceased their 





current activity and entered their failsafe mode. 


The results also show that the client-server 


relationship worked correctly, and can likely scale to a 





greater number of MM-Clients operating on differing network 
configurations. Also, with the exception of possibly 


needing additional onboard memory for the Physical Servers, 





there is plenty of capacity with respect to CPU cycles, hard 





drive space, and network utilization for each of the 





physical test bed servers to accommodate more simultaneous 


VMs, as well as more complex network configurations. 


Next, in Chapter VI, we discuss our conclusions. We 





also discuss our thoughts on future work in this area of 
study, to include code improvement, expansion, and security 


implications. 
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VI. CONCLUSIONS AND FUTURE WORK 


A. CONCLUSIONS 





In 








this thesis, we proposed a solution to DoD 


overreliance on network analysis red teams for training and 


evaluation of network administrators by designing a novel 


network training tool. This tool allows the integration of 





network evaluation into the highly complex training events 


typical of U.S. military training exercises. The system we 


constructed had the following characteristics: 





It was safe enough for production or operational 





environments. Emulated behaviors would cease on 
command and “roll-back” to a pre-exercise state. 


Losses of network connection wer treated as 





instructions to cease behaviors. This would allow 
training to take place on the same network on 


which the trainees perform their mission. 


Only malware behaviors were constructed, not 
actual malware itself. Though we demonstrated the 
properties of a notional worm on the network, 


there was no actual malware involved. 





The system constructed was distributed across the 





network, allowing for the trainer to be located 


anywhere on the network, local or remote. 





We then set out to construct a prototype for such a 


system, 


Following 





which we discussed in detail in Chapter IV. 





our treatment of the constructed system, we 








discussed 


the test bed that we created to test our system 
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concept vis-a-vis the goal we had set for ourselves, and 


proceeded to discuss the specific results acquired after 





establishing the test-bed and conducting a set of tests. 


We discovered that it is certainly possible to 


construct a system with the attributes discussed above. We 





believe that this has the potential to revolutionize 
training for not only network administrators, but for the 


decision makers that are affected by malicious actions 





against such networks. We also noted that the system 





performs as expected with regards to safety, namely, that it 
did not perform uncommanded behavior at any point during 


testing. The system ceased all emulated behaviors within a 





suitable small time upon receipt of the trainer injected 
“cease-action” command—-without exception. This particular 
system quality is essential for its forecasted use on 
operational networks, and in this capacity, the MM-System is 


ready for a validation in an operational or production 














environment. 
We also discovered w ssentially built a botnet, as 
discussed in Chapter , complete with a command and control 











architecture and  slave-node functionality without’ the 





dangerous behavior of actual propagation across the network. 


This, we believe, could form the basis of an existence proof 





for the size to which our Malware Mimic System architecture 








can scale. Using Conficker as an example (also discussed in 











Chapter ), it is possible that this tool could scale to 





thousands of hosts, with some modification to the code, 


allowing the training and evaluation of the administrators 








of networks on the order of Tier One Internet Servic 


Providers. 
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B. FUTURE WORK 


1. Code Improvement and Extension 








As with any software early in its lifecycle, the cod 
needs refinement. For example, we found that the keying 


system for our data structure (mapping between keys and 











actual nodes) was unwieldy. It is essential that this key 


uniquely correspond to a  MM-Client node, which we 





accomplished by using a combination of the given node’s host 
name and a user assigned name given at invocation. However, 


this does not scale well, as it requires a unique naming 











system to be created and tracked by those parties 
responsible for instantiating the nodes. Instead, we would 
suggest using a naming scheme that would allow for unique 





names to b generated and maintained by the hosts 


themselves, without involvement by any human user. 





Furthermore, the Data Structure will, at some point, need to 





be replaced by a robust, industrial grade database that can 


maintain records on the order of thousands, vice the data 














structure we utilized, discussed in Chapter 





We described a local “kill server” and its role in the 








communication protocol of the MM-Mimic system in Chapter 














, but we provided no implementation. We foresee a 





modification to the MM-Client code that allows for local 





pre-emption or blocking of remote taskings using UDP-based 


requests to local “kill server” located on the trainee 





network. Construction of this “kill server” could largely 





be modeled on th MM-Server architecture discussed in 














Chapter ; again, using datagram vice stream socket 





connections. 
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There ar several improvements that could affect the 
scalability of the software. As it stands, there is no 


organic capability implemented to remotely “push” MM-Client 





code to machines on the trainee network. Additionally, 
there is no capability to distribute updates over the 
network. The implication of this is that the MM-Client nodes 
must have all desired behaviors preprogrammed into the MM-— 


Client software on the host machine. A more agile solution 





would be to have modules of behaviors sent to MM-Client 





nodes via software push, increasing the flexibility, 
adaptability, and, possibly, security of the MM-Mimic 
system. Such a scheme would require authentication and 


integrity verification to ensure only authorized behaviors 





are distributed. 


2. More Advanced Modules 





The training value in our first iteration of the MM- 


System is limited. That said, there is a rich framework 





laid out upon which more complex modules, with corresponding 


training scenarios, could be developed. We foresee modules 





that would allow the MM-Client nodes to mimic virus 











behavior, as outlined in Chapter , including, but not 








limited to host machines showing virus “signatures” that 


would be visible on installed anti-virus systems. Such 





signatures would need to be “hidden,” likely through 
encryption, until the behavior is commanded. MM-Client 
nodes could show “pop-up” messages that would instruct users 
to contact their system administrators. MM-Clients could 


increase their system resource consumption, increasing the 





discomfort level of human users utilizing the system. More 








advanced and realistic worm behaviors could be programmed; 
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simulation of worm behaviors propagating across a network, 


or delivering a “payload” would be an example of this. 


We have limited ourselves to discussing the behaviors 
of malware—-worms, botnets and the like. However, human- 
centric behavior continues to be a critical aspect of system 


hardening. Emulating such behavior to train operators to 





recognize it when it occurs could be beneficial. Determining 


whether or not there exists discernable differences between 





the observable behaviors of a human adversary, a “hacker” in 
popular parlance, and programmatic behaviors of the MM- 


System would be a first step to implementing “human” 





behaviors. We believe that the emulated threat behaviors of 








th MM-System could be expanded to include those of 
“hackers” as well, perhaps through well-scripted “mock” 


user-sessions. 


3. Increase Scale of Test Bed 





Code development is one area for further advancement; 


but the path forward for the project in the whole will rely 








on the system being tested on human users on ae scale 





representative of the training networks to which the system 
is destined. Towards this, expansion of the test bed will 


be required to an appropriate number of clients well beyond 





the twenty used for initial test bed. Testing of the system 


should also be conducted on networks more complex than the 





Single subnet system we utilized, again, to validate the 





system for networks more representative of its anticipated 
use. Additionally, as discussed in Chapter V, we relied on 


a protocol analyzer to demonstrate our externally-observable 
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network behaviors. We must additionally test our system 


against common intrusion detection systems used in the field 





today, e.g., Snort. 


4. Security Implications 


We made no security assumptions in our architecture, 





nor did we treat security implications in our 
experimentation. Before the MM-System is ready for field 
use, security analysis must be performed. The architecture 


should be suitable for this environment, however, as the 




















system architecture was conceived with security in mind, 
with an eye on eventual deployment on DoD networks. Java is 
common on DoD networks. Host-based network software is 
common on DoD networks. No mechanism yet exists to prevent 


unauthorized third parties from remotely commanding MM-node 
behavior, but again using existing botnets such as Conficker 
as an example, this too should be possible. But the 
fundamental approach to the system is its greatest asset: 
only malware behaviors are employed on the trainee network, 
not actual malware. Therefore, no behavior can happen on 


the network that is not explicitly coded into the MM- 








Clients. In this way, th MM-System behaviors can _ be 
tailored according to the risk tolerance of the trainee 


networks. 
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APPENDIX A. MM-SERVER: CANDCSERVER.JAVA 


[KOR RR KKK KK KK RK I I I I I I I I RK I OK / 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


Program: Malware Mimic Server 


Top level for the MM-Server. Interfaces with the user 
via the UI. Handles incoming TCP connections on all 
interfaces on TCP.port == 30000 with remote or local 
MM-Clients. Maintains and closes TCP sessions with 
MM-Clients. Translates user instructions to MM-Clients 
and passes the commands to MM-Clients. Allows input 
from MM-Clients to UI. Maintains state on MM-Clients. 
FILE: ClientProgram. java 

















USAGE: ./MM-Server <with no paramters> 


AUTHORS: W. Taff and P. Salevski 





DATE: 22 January 2011 


ay 
Ai 
*/ 
*/ 
Wie 
*Y, 
*/ 
ay 
ad 
A} 
A 
*/ 
AG 
2), 
4G 
ey 
oy, 
ae 
*/ 


[KOR KR KKK KK KR I IR I I I I OR OK / 


package commandserver; 





import java.io.IOException; 
import java.net.*; 


/ 


+ + + FF + FF F F HF FX 


Sy 


* 


The server - top level for program, and listener for connections. 


Initializes the database. Starts the UI. 

Sits and listens for connections, spins off CC-Communicators 
to handle them and passes off Socket to same, then reset to 
listen. 


@author W. Taff and P. Salevski 


public class CandCserver { 


[** 
* @param args 
Ry 


public static void main(String[] args) { 





TISISISTITITITIAI TATA IITA TATA AAAI TATA 
//INITIALIZATION 
TISISIITLTITITIATIT IAAT ATI TAA TIAA AAAI ATT 


ClientDatabase dataBase = new ClientDatabase(); 


7 BS) 


Integer listenPort = 30000; 





Socket clntSock 


//start the UI 


= null; 


Thread GUIthread = new Thread ( 





new CandCserverMenuUlI (dataBase) ); 


GUIthread.start(); 


try { 


ServerSocket server = new ServerSocket 





System.out.printin ("Server Listening on port 


while 


(listenPort); 


W 


(true) { 


System.out.println ("Waiting"); 





clntSock = server.accept (); 
System.out.println ("Connection Accepted 
from " + clntSock.getInetAddress() ); 


Thread thread = new Thread (new 
ClientCommunicator(clntSock, dataBase)); 





thread.start(); 


}//end while 


} 


catch (IOException ioe) { 
System.err.printlin (1i0e); 
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APPENDIX B. MM-SERVER: CANDCSERVERMENUUL . JAVA 


package commandserver; 
//Filename: CandCserverMenuUl. java 
//21 December, 2010 


import java.util.Scanner; 


* 


/ 
Rudimentary command line, console based ui 
Used for troubleshooting and functionality verification; will 
likely be replaced with graphical version. 











@author W. Taff and P. Salevski 


+ + FF + F FF F F 


a 


public class CandCserverMenuUI implements Runnable { 


/** need access to db to invoke methods */ 
private ClientDatabase db; 


public CandCserverMenuUI (ClientDatabase dbInput) { 


this.db = dbInput;} 


/* (non-Javadoc) 
* @see java.lang.Runnable#run () 
*/ 


public void run() { 














uiConsole(); 


}//end run 


private void uiConsole() { 

//OF FORM: commands, module numbers (if any), and targets 
// e.g. MOD_0:ALL or maybe PRINT:ALL 
// if no target, assume ALL 


Scanner adminInputScanner = new Scanner (System.in); 
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String inputString = ""; 


int cmdDelimValue; 


String command 


String target 


= null; 





null; 


int moduleNumber = 999; 


while (inputString.compareTo ("QUIT") !=0) { 


inputString = adminInputScanner.next (); 


inputString = inputString.toUpperCase(); 


cmdDelimValue = inputString.length(); 


try { 


if (inputString.contains(":")) { 


cmdDelimValue = 
inputString.indexOf (":"); 


command = inputString.substring(0, 
cemdDelimValue) ; 


target = 

inputString.substring (cmdDelimValue 
+ 1); } 

else { 


command = inputString; 


target = "ALL"; 


if (inputString.contains("_")) { 


int modDelimValue = 
inputString.indexOf("_") + 1; 


moduleNumber = 
Integer.parseInt (inputString. 
substring (modDelimValue, 
cmdDelimValue) ); 


command = command.substring(0, 
modDelimValue -1 ); 
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// 
// 


} catch 





(Exception e) { 


e.printStackTrace(); 





GI 





System.out.printlin("] 


INPUT") ; 


ERROR ON PARSI 


System.out.println("Command is:" 


System. 


System. 





r. 


+ command ); 


+ target ); 


out.printin("Target is:" 


out.printin("Module Number is:" 


+ moduleNumber ); 


//THE COMMANDS 


else if 


} 


else if 


else { 


if (command.compareTo("PRINT") == 0) { 
print (target); 
(command.compareTo ("HALT") == 0) { 
halt (target); 
(command.compareTo("MOD") == 0) { 
mod(moduleNumber, target); 
db.getRecord (command) .getCC(). 


719 


OF 


sendMessage2Client (value) ; 





}//end else 


}//end while 


System.out.printin("Got quit command") ; 


System.exit (0); 


private void mod(int moduleNumber, String target) { 


System.out.printin("Running MOD_" + moduleNumber) ; 


db.run_module (moduleNumber) ; 


private void halt (String target) { 


if (target.compareTo ("ALL") ==0) { 





System.out.printin("Halting All!"); 
db.halt_module(); 


} 


[** 
* Print records in the database. 
* @param target 
*/ 
private void print (String target) { 
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if (target.compareTo ("ALL") ==0) { 





String printBuffer = db.getAllrecordsFromDB () ; 





System.out.println("Host, Exercise, Inbox, 
Status"); 





System.out.printin(printBuffer) ; 


}//endif 


}//END print () 


}//end class 
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APPENDIX 


C. MM-SERVER: CLIENTCOMMUNICATOR.JAVA 


// Filename: ClientCommunicator. java 
// 21 December, 2010 


package commandserver; 


import java.net.*; 
import java.io.IOException; 
import java.io.PrintStream; 


* 


/ 


@author W. 7 


+ + + FF F F HF 


™~ 


public class C]l 





A handler that maintains the session between server and client. 
Runs as a thread that is started by server. On run, spins off 
a threaded Client Listener to accept input, and calls MM-node 
for Name and Status. 


Taff and P. Salevski 





ientCommunicator implements Runnable{ 








/** Socket passed to CC by the SocketServer */ 
private Socket ccSocket; 


/** The output stream use to push our messages onto the wire 
private PrintStream outPrintStream; 


/** the location of the db, so we can call it's methods */ 
private ClientDatabase db; 


/** the keyname of the host that the CC relates to */ 
private String keyname; 


// CONSTRUCTOR 


public 


ClientCommunicator (Socket passedSocket, 
ClientDatabase db) { 


this.ccSocket = passedSocket; 





this.db = db; 


//make the output stream. input stream made in run() 
rye tt 


this.outPrintStream = new PrintStream ( 
ccSocket.getOutputStream() ); 


} catch (IOException e) { 
e.printStackTrace(); 
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ai 


}//end constructor ClientCommunicator () 


/* (non-Javadoc) 
* @see java.lang.Runnable#run () 
*/ 

//@Override 

public void run() { 














ccListenerStarter () 


, 





outPrintStream.printin("#GETNAME") ; 











}//end run() 


[** 

* Starts the ccListener. 

* Use the ccListener for input from the MM-node. */ 
private void ccListenerStarter () { 


Gry 
//spin off new ccListener 
Thread listenerThread = new Thread ( 


new ClientCommunicatorListener ( 
ccSocket.getInputStream(), db, this)); 





listenerThread.start(); 





} catch (IOException e) { 


e.printStackTrace(); 


}//end ccListenerStarter () 
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[** 

* Externally callable session terminator-closes socket. 
* Also updates the status of the MM-Client in the db. 
Ay: 


public void terminateSession () { 





sendMessage2Client ("Session Terminated") ; 





db.getRecord(keyname) .setClientStatus ("TERMINATED 











ccSocket.close(); 





} catch (Exception e) { 


e.printStackTrace(); 
db.getRecord(keyname) .setClientStatus ("LO 
ST"); 





}//end terminateSession() 


[** 
* Pushes any input string down to MM-Client 
* @param msg 
ie 

public void sendMessage2Client (String msg) { 





outPrintStream.println(msg) ; 


[** 
* @return the keyname 
*/ 
public String getKeyname() { 
return keyname; 


} 
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[** 
* @param keyname the keyname to set 
w/. 
public void setKeyname (String keyname) { 
this.keyname = keyname; 








} 


}//end class 
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APPENDIX D. MM-SERVER: CLIENTCOMMUNICATORLISTENER 


package commandserver; 
//Filename: ClientCommunicatorListener. java 
//21 December, 2010 


import java.io.*; 


[** 
* @author W. Taff and P. Salevski 
* Handles input from MM-node. 


* Parses MM-node messages and makes appropriate system calls. 
* 


*/ 


public class ClientCommunicatorListener implements Runnable{ 








SITITITITITS ISIS TIT TI TIAA AAAI AISI STITT TT 
//DATA MEMBERS 
JISTITITITITIATIATA TITAS TATA TIAA IAA AIT ITT 














/** passed —- will bolt on top a BufferedReader */ 
private InputStream inStream; 


/** use for reading incoming messages from MM-Client */ 
private BufferedReader inBufferedReader; 





/** gives ability to call ClientDatabase fns */ 
private ClientDatabase db; 














/** gives ability to call back to the calling CC */ 
private ClientCommunicator parentCC; 








SITITITITSIS ISIS IATA TIAA AA AAAI TIT IITITA TT 
/ /METHODS 
JISISTLTITITIAIATA TIT I TS TITITATAAIAAAATI TTT 





//CONSTRUCTOR 
public ClientCommunicatorListener (InputStream inputStream, 
ClientDatabase db, ClientCommunicator callingCC) { 
this.db = db ; 


this.inStream = inputStream; 


this.inBufferedReader = 
new BufferedReader (new InputStreamReader (inStream) ); 
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this.parentCC = callingCC; 


public void run() { 


//Need try/catch to make severed sessions graceful 
try { 


listenLoop(); 





} catch (NullPointerException e) { 





e.printStackTrace(); 





catch (Exception e) { 


e.printStackTrace(); 


finally { 


System.out.printin("Connection Lost to " + 
parentCC.getKeyname ()); 


parentCC.terminateSession(); 
db.getRecord (parentCC.getKeyname()).setClientStatus ("LOST") ; 





}//end run () 


[** 

* Main loop of CCListener. 

* Blocks on readlines from MM-Client. Calls appropriate db 
* methods based on input passed up from MM-Client. 


* @throws Exception 
* 


*/ 


private void listenLoop() throws Exception { 








Boolean keepGoing = true; 





String textReceived = ""; 
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while ( keepGoing ) { 


textReceived = inBufferedReader.readLine(); 








if ( textReceived.compareTo ("QUIT") ==0 ) { 
parentCC.terminateSession(); 


keepGoing = false; 





else if ( textReceived.contains ("GETINBOX") ) { 


parentCC.sendMessage2Client (db. getRecord ( 
parentCC.getKeyname()).getClientInbox() ); 








else if ( textReceived.contains("=") ){ 


setVariableValue (textReceived) ; 





}//end if 





//RESET THE TEXT OR WE SPIN 
textReceived = ""; 











H 








r 








} // end while 


[** 
* Set a db key/value pair based on input from MM-client 
* 


* @param textReceived 
#7: 


private void setVariableValue (String textReceived) { 





int delimValue = textReceived.indexOf ("="); 





String key = textReceived.substring(0, delimValue) ; 





String value = textReceived.substring(delimValue + 1); 
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if (key.compareTo ("NAME")==0) { 





parentCC.setKeyname (value) ; 
db.createRecord(value, parentCC); 

} 

else if (key.compareTo ("STATUS") ==0) { 


//with key, set the status 

















db.getRecord (parentCC.getKeyname()).setClientStatus (value) ; 
} 
else if (key.compareTo ("EXERCISE") ==0) { 

db. getRecord (parentCC.getKeyname()).setExercise (value) ; 
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APPENDIX E. MM-SERVER: CLIENTDATABASE. JAVA 


package commandserver; 
// Filename: ClientDatabase. java 
// 21 December, 2010 


import java.util.TreeMap; 
import java.util.SortedMap; 
import java.util.Collections; 








[** 

* The database of ClientRecords. 

* Uses a TreeMap (for now) as the data structure, 
and ClientRecords as the nodes. 





* 
* 
* @author W. Taff and P. Salevski 
* 
* 


/ 


public class ClientDatabase { 








SITITITITIT ISIS TIT TI TIAA AAAI AIA ISIS TIT T TT 
//DATA MEMBERS 
TISTITIIITITIATITA TIT IST T ATI T I A AAA T I T I TTT 














/**the database data structure of ClientRecord*/ 
private SortedMap< String, ClientRecord > dbase = 
Collections.synchronizedSortedMap ( 
new TreeMap< String, ClientRecord >() ); 


SITITITITITS IIIT TATA ITAA AAA AIA IATA TTT 
//METHODS 
TISTIILIITITITIAI TIT I TST TATATATIAAAATI TIT T 





[** 
* Constructor for ClientDatabase 
* 
* x / 

public ClientDatabase () { 


} 
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[** 
* Creates a record in the database. 
* @param hostID - uid_host of the host we are creating (used as 
key) 


* @param ccIn - the calling Client Communicator 
* @return True if successfully created 
* * / 


public Boolean createRecord(String hostID, ClientCommunicator ccIn) { 
ClientRecord newRecord = new ClientRecord(ccIn, this); 





try { 
dbase.put (hostID, newRecord) ; 


System.out.printin("Added record for " + hostID); 





catch (ClassCastException cce) { 


System.err.printin(cce) ; 


catch (NullPointerException npe) { 








System.err.printlin (npe) ; 


return true; 


[** 

* get a client record from the database. 

* Pulls an instance of ClientRecord from the database, for use as 
* a helper function for class functions. 

* @param hostID - uid_host of the host of interest 

* @return ClientRecord 

* 

* 


ay 
public ClientRecord getRecord(String hostID) { 
// gets the record from the TreeMap that has the hostID key 
ClientRecord tempClientRecord = null; 
try { 
tempClientRecord = dbase.get (hostID); 








} 


catch (ClassCastException cce) { 
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System.err.printin(cce) ; 
} 
catch (NullPointerException npe) { 

System.err.printin(npe) ; 











} 


return tempClientRecord; 


[** 


* 


* 


* 


* 


Returns String of all database inbox and status for all MM-C. 
Typically used for console troubleshooting. 


@return returnString, a string of all db parameters by client 


A 


public String getAllrecordsFromDB () { 
String returnString = ""; 
for (String keyString : dbase.keySet() ) { 


+ + FF + F F F 


returnString += keyString + "," + 
dbase.get (keyString) .getUID_ExerciseNetwork() +"," + 
dbase.get (keyString) .getClientInbox() + "," + 
dbase.get (keyString) .getClientStatus() +"\n" ; 








}//end for-loop 


return returnString; 


* 


deletes a client record from the database. 

Will attempt to remove a client record from the database, 
based on the host UID provided. 

@param hostID —- uid_host of the host of interest 

@return True of record and deleted, False if record not found 





ay: 


public Boolean deleteRecord(String hostID) { 





// tries to delete the record 
Boolean deleteSuccess; 





ClientRecord tempClientRecord = null; 





try { 


tempClientRecord = dbase.remove (hostID) ; 
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} 





catch (ClassCastException cce) { 


System.err.printin(cce) ; 


} 


catch (NullPointerException npe) { 








System.err.printin(npe) ; 


if (tempClientRecord == null) 





deleteSuccess = false; 











deleteSuccess = true; 


return deleteSuccess; 


} 


TITTTTTTTTTTATTTTAT TAA 
// UPDATE (SET) METHODS 
TITTTTTTTTTTTTAT AAA T 

















[** 
* Halts running module —- OVERLOADED METHOD. 
* Called without arguments, halts running module in all 


























* modules. Simple iteration over dbase, setting client 
* inboxes to HALT. 
*/. 


public void halt_module() { 
for (String keyString : dbase.keySet() ) { 
dbase.get (keyString) .setClientInbox( "HALT" ); 


}//end for-loop 


}//end halt_running_mods () 
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[** 

es Starts running module —- OVERLOADED METHOD. 

* Called without target arguments, starts running module in all 
* modules. Simple iteration over dbase, setting client 

* inboxes to MOD_X, where X is the module number. 

* 

* @param moduleNumber 

*/ 


public void run_module (int moduleNumber) { 
for (String keyString : dbase.keySet() ) { 


dbase.get (keyString). 
setClientInbox("MOD_" + moduleNumber) ; 


}//end for-loop 


}// end run_module() 
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APPENDIX F. MM-SERVER: CLIENTRECORD .JAVA 


package commandserver; 
// Filename: ClientRecord. java 
// 21 December, 2010 





[** 
* ClientRecord the records in the database. 

* Includes all fields associated with a single client, except for 
* it's uid, which the record is keyed by in the database. 

* @author W. Taff and P. Salevski 

* 
*/ 


public class ClientRecord { 

















LISTITITITITITIAI TITAS TITATA TAA TAT ITT 
//DATA MEMBERS 


TITTSTTTTTTTTTTTTTTATT TATA TATA TATA AAA ATTA 




















/**unique identifier of th xercise network */ 
private String uid_ExerciseNetwork,; 








/**status of the client, set by the client, read by server */ 
private String status; 


/**inbox of the client, set by server, read by client */ 
private String clientInbox; 


/**where the ClientCommunicator lives */ 
private ClientCommunicator cc; 
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TISTITITITITITIAI AIT ITAA TATA TIAA AAT ITT 
//METHODS 
TISIITLTITITITIAI TIA IST TIT ATAA A A AAA TITI TT 














[** 

* Constructor for a ClientRecord called by ClientDatabase. 

* Gets passed hostID, exerciseID and a socket. Initializes 

* the class with the passed params, and makes empty for those 

* params that it does not yet have. 

* @param hostID - uid_host of host we are creating (used as key) 
* @param exerciseID the UID of the exercise 

* @param passedCC the ClientCoummincator for the client. 

* @param db - the database of clients 

af 


public ClientRecord (ClientCommunicator passedCC, ClientDatabase 
db) { this.cc = passedCC; 





this.uid_ExerciseNetwork = "NOT_SET"; 








this.status = "INITIALIZED", 





this.clientInbox = "INITIALIZED", 





TISISTIIITITITITI SIS ISAS T I TTT 
// GET METHODS 
TISIIIITITITITITIT ISIS TITAS TTT 














[** 
* returns the content of the client's inbox 
* The client inbox is set by the server, but read by 











* the client. Consists of a plain text string value. 
* @return clientInbox - the contents of the client's inbox 
x 


public String getClientInbox() { 


return clientInbox; 


public ClientCommunicator getCC() { 


return this.cc; 
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[** 
* for the commandServer to get status of the individual client 
* @return status - the contents of the client's status box 
Kp 
public String getClientStatus () { 
return status; 





} 


[** 
* return the UID of th xercise network 
* @return uid_ExerciseNetwork 
a] 
public String getUID_ExerciseNetwork() { 
return uid_ExerciseNetwork; 














} 


TISISTIIITITITITITS ISIS TIT T ST 
// SET METHODS 
TISISIIIITITITITIT ISIS TITAS 














Allows server to write message to client inbox. 

Only servers shall write to the client inbox. 

@param hostID - uid_host of the host of interest 

@param message - String of message FROM server TO client. 
*/ 


public void setClientInbox(String message) { 





+ + + F F F 


clientInbox = message; 
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[** 
* Allows client to set their status in status box of record. 
Only clients shall write their status to their status box. 





* Read by the server to ascertain status of the client. 
* @param message - String of status FROM client. 

* 

x x / 


public void setClientStatus (String message) { 


status = message; 





* 
* Allows client to set exercise in exercise field of record. 

* Only clients shall write their exercise to their exercise 

* field. Read by the server to ascertain exercise of the client. 
* 

* 

* 








@param message - String of exercise FROM client. 


*/ 


public void setExercise (String message) { 











uid_ExerciseNetwork = message; 


} // end of ClientRecord class 
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APPENDIX G. MM-CLIENT: CLIENTPROGRAM. JAVA 


[KOK KR KKK KK KK KR RK I I I IR RK OK OK KK / 
































f% ay 
[* Program: Malware Mimic Client */ 
1 as af 
[® Handles client side communications. Controls session Ae. 
/* with remote server. Executes commands from server on Hy: 
/* local machine. Ap. 
iE Ad 
/* FILE: ClientProgram. java */ 
[% ay 
/* USAGE: ./MM-Client hostname exerciselId srvrName srvrPort*/ 
fe ay 
/* hostname name of host aif 
Ex serverName IP addr of server, in dotted quad */ 
/* serverPort Integer port number of remote server eg 
/* */ 
/* AUTHORS: W. Taff and P. Salevski ey 
[x */ 
/* DATE: 22 January 2011 a; 
L% ay 
[* */ 


[KOR KKK KK KK KK KR RI IR RK OK OR KK / 


package mimicClient; 











[** 
* The MM-Client software for remote host. 
* Handles both sides of communication with the remote server 
* (up and down) as well as local execution of remotely (server) 
* commanded methods. 
* 
* @author W. Taff and P. Salevski 
* 
*/ 
public class ClientProgram { 
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[** 

* Top level main() for program. 

* Loops, starting clientController with each iteration. If 
clientController dies, handles that exception, and restarts. 
So far, is self perpetuating - i.e., will loop until killed 
externally. 





@param args hostName, exercise Id, server IP.addr, server port 


/ 


public static void main(String[] args) { 


+ + + + F 





while (true) { 


ery 4 


new ClientController(args[0], args[1], args[2], Integer 
-parselInt (args[3])).run(); 





} catch (NumberFormatException e) { 
e.printStackTrace(); 
System.out.println("Check your parameters!\n" + 


"Expect hostId exerciseID serverIP.addr " + 
"serverIP.port" ); 








System.exit (2); 





catch (ArrayIndexOutOfBoundsException e) { 
e.printStackTrace(); 
System.out.println("Check your parameters! \n" + 


"Expect hostId exerciseID serverIP.addr " + 
"serverIP.port" ); 








System.exit (2); 





catch (NullPointerException f) { 





f.printStackTrace()j; 





catch (Exception e) { 


e.printStackTrace(); 
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finally { 


Pay fi 


Thread.sleep (10000); 


} catch 





(Interrupted 


Exception e) 


e.printStackTrace(); 


} 
}//end while 
}// end main () 


}//end Class 
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APPENDIX H. MM-CLIENT: CLIENTCONTROLLER. JAVA 


package mimicClient; 


import java.io.*; 

import java.net.InetAddress; 
import java.net.Socket; 
import java.util.Random; 


* 


/ 
Controller class for the Malware Mimic client. 
Started by ClientProgram. IPC code based on code by 
John Yeary. 





@author W. Taff and P. Salevski 


+ + FF + F F HF F 


™~ 





public class ClientController { 





LISTSTLTITITITIAI TIA ITAA TATA TIAA AI TIT TTT 
//DATA MEMBERS 
TISIITLTITITITIAI AIA ITTAIA IT ATATAAAAATA TIT T 














private String hostName; 


private String os_name; 





private String exerciseID ; 


private Runtime localRuntime; 





private String status; 
private InetAddress localMachine,; 
private Socket socket; 


private String textReceiveBuf; 





private BufferedReader inBufferedReader,; 
private PrintStream outPrintStream; 
private String serverAddr; 


private int serverPort; 
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TITLILSSTLTTLTS ASTI IATA ATTA ATI 
//METHODS 
ZITLILTILTLTSTS TTS 7 
[** 
* Constructor for ClientController 
* @param serverPort the port of the remote server to use 
* @param serverAddr the string dotted-quad server address 
* @param hostName the hostname of local machine; will append 
* @param exerciseID 
* @throws Exception 
* 
*/ 
public ClientController (String hostName, String exerciselID, 
String serverAddr, int serverPort) throws Exception { 
super (); 
os_nam = System.getProperty("os.name"); 
localRuntime = Runtime.getRuntime(); 
status = "READY"; 
localMachine = InetAddress.getLocalHost(); 
socket = new Socket (SserverAddr, serverPort); 
this.hostName = hostName + localMachine.getHostName() ; 
this.serverAddr = serverAddr; 
this.serverPort = serverPort; 
this.exerciseID = exerciselID; 
} 
[** 
* Main body of the clientController. 
* Loops until receives a halt command, checking the inbox 
* located on the remote server, and executing any commands. 
* 
* @throws Exception 
*f 





public void run() throws Exception { 


initializeConnection(); 


//and then start looping and keep checking inbox 
whil ( textReceiveBuf.compareTo ("HALT") !=0 ) { 
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Thread.sleep (5000) ; 


outPrintStream.printin ("GETINBOX") ; 








textReceiveBuf = inBufferedReader.readLine(); 


if ( 


if ( 





System.out.printin (textReceiveBuf) ; 
textReceiveBuf.compareTo ("MOD_0")==0 ) mod_0(); 
textReceiveBuf.compareTo ("MOD_1")==0 ) mod_1(); 
textReceiveBuf.compareTo ("MOD_2")==0 ) mod_2(); 


Ls 





}//end while 


//CLOS 
outPri 





r 


CONNECTION 











ntStream.printin("CLOSING..."); 


Thread.sleep (1000); 





socket.close(); 


}//end run() 


+ + + + F F FH 


/ 


private void initializeConnection() throws 


System.out.printin("Connected ... waiting for #GETNAME") ; 


@throws 


Called by run(), 
connection, 





Exception 








Initializes the connection with the remote host. 
connects with the remote host, and upon 
sends initialization parameters to the server. 


Exception { 














outPrintStream = new PrintStream(socket.getOutputStream () 


inBuffered 


//GIV 


Reader = new BufferedReader ( 





new Inpu 








E TIM 











EF FOR INITIAL COMMAND TO ARRIV 
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tStreamReader (socket.getInputStream())); 


GJ 


i 


Thread.sleep (1000) ; 





if (inBufferedReader.ready()) { 








textReceiveBuf = inBufferedReader.readLine(); 
System.out.printin(textReceiveBuf) ; 


} 


//if server says getname, tell it 




















if (textReceiveBuf.compareTo ("#GETNAME")==0 ) { 
outPrintStream.printin("NAME=" + hostName) ; 
outPrintStream.printin("STATUS="_ + status); 
outPrintStream.printin("EXERCISE=" + exerciselID); 


























}// end initializeConnection () 


[** 
* A hping scan of 10 sequential ports from a random start port. 
* Scans server in range of 1 to 1024. 





* @throws InterruptedException 
*/ 
private void mod_2() throws InterruptedException { 





status=("MOD_2"); 
outPrintStream.printin("STATUS="_ + status); 


int randomPort = new Random().nextInt(1014) + 1; 


Eny ef 


Process p = null; 








if (os_name.contains("Linux")) { 
p = localRuntime.exec("/usr/bin/sudo " + 
"/usr/sbin/hping3 -c 10 -s 1-p" 
randomPort + " -S " + serverAddr) ; 
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randomPortt+t+; 


System.out.printin(randomPort) ; 


} 


else { //is windows 


p = localRuntime.exec("hping -c 10 -s 1 -p " 
+ randomPort +" -S "+serverAddr) ; 





System.out.printin(randomPort) ; 





} catch (IOException e) { 


e.printStackTrace(); 


System.out.printin("Mod 2 Iteration Complete"); 


}//end mod_2() 


[** 

* A 5 ping module. 

* Pings server 5 times then stops. 
tf 


private void mod_l() { 


status = "MOD_1"; 


outPrintStream.printin("STATUS="_ + status); 


try { 
Process p; 
if (os_name.contains("Linux")) { 


p = localRuntime.exec("/bin/ping -c5 " + serverAddr) ; 





} 


else { //is windows 
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p = localRuntime.exec("ping -n 5 " + serverAddr) ; 


BufferedReader buffRdr = new BufferedReader ( 
new InputStreamReader (new BufferedInputStreanm ( 
p.getInputStream()))); 


String line; 


while ((line = buffRdr.readLine()) != null) { 





System.out.printin(line); 


} 


try { 
if (p.waitFor() != 0) { 


System.err.println ( 
"exit value = " + p.exitValue()); 


} 
catch (InterruptedException e) { 
System.err.printin(e); 








} catch (IOException e) { 
e.printStackTrace()j; 
} 


System.out.printin("Mod 1 Iteration Complete"); 


}//end mod_1() 


[** 

* Sends a status update message to the server. 
* Equivalent to an idle command. 

* 

*/ 


private void mod_0() { 





status=("MOD_0") ; 


outPrintStream.printin("STATUS="_ + status); 


} //end mod_0() 


}// end class 
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